You’ve carefully assessed the risks in your new system. You’ve considered the implementation and eliminated bad implementation decisions and removed unnecessary features that involved extra risk. Considering the result, you note that there is still risk. So, what do you do? You try to mitigate the remaining risk. Risk mitigation does not remove the risk… Read More »
Many people doing risk management assert that you cannot eliminate risk. Those people are partly right. If you are willing to modify the functionality of a program or system, you can eliminate some kinds of risk, Obviously, this is much easier early in the design or implementation of a system. Trade-offs to Eliminate Risk Part… Read More »
One way to think about risk is to decide if a feature is naturally risky, or if the risk is a result of the implementation of the feature. Stealing some terminology from the description of software complexity, I call these Inherent Risk and Accidental Risk. Risk Creep Sometimes unnecessary risk creeps into a system through… Read More »
When developing software, there are many different dimensions of risk you might consider. There is an enormous amount of information available on Risk Assessment, consider this to just quickly skimming over the topic. Depending on your understanding of risk (or your paranoia), trying to assess risk can be a difficult task. There are several approaches… Read More »
Any project or software includes potential risks. Will it do the job or fail? Will it leak user information? Will it serve as a springboard for attacking other systems? When you realize the need to learn how risky your software is, there are a number of approaches to assessing that risk. If a piece of… Read More »
You might wonder if code review is necessary if your team practices pair programming. (Assuming that your team does either code review or pairing.) Pair programming was originally one of the practices pushed by Extreme Programming (XP). The reasoning was pretty straight-forward, if we assume code review produces better outcomes, more frequent code review should… Read More »
It’s time for another post in my intermittent series of Best Practices Gone Bad (BPGB). This time we’ll cover the dark side of the Single Responsibility Principle (SRP). According to Robert Martin: A class should have one, and only one, reason to change. The basic concept is easy. Every object or method should be responsible… Read More »
The Art of Readable Code Dustin Boswell and Trevor Foucher O’Reilly Media, Inc., 2012 When I saw this book, it seemed like a great idea. I’ve spent my entire career with legacy codebases, trying to make them better. A book that covers ways to make code more readable, and therefore, more maintainable is a wonderful… Read More »
There are numerous issues that you need to consider when developing almost any software. If you are working on software that connects to a network in any way, security is yet another thing that you need to consider. To introduce this series on Designing Secure software, I’m going to talk about something that normally gets… Read More »
This is another post in my intermittent series of Best Practices Gone Bad (BPGB) Today, we are going to take another side-step into version control. Most development groups use version control of some form. Whether you prefer Subversion, Git, Mercurial, Bazaar, Clear Case, or any of the many others, version control is an important technique… Read More »