Following this principle dramatically improves quality. The reason is that changing code allows a risk of altering the meaning (semantics) of some part of that code. Because of that, whenever we change code, we run the risk of breaking code that depends on that code.
So how does that relate to fixing bugs? Fixing a bug almost always involves altering the semantics. The old meaning was wrong (buggy), so we need to fix it. This leads to some interesting paradoxes. First...
Fixing bugs is one of the most risky things you can do to a software application.
The better you have followed good design principles, the more this is true. Conversely, in less well designed systems, it is less true...
If you have a poorly designed system, then bug changes are not particularly risky.
This is because in a poorly designed system, all changes are equally risky.
You can mitigate the impact of bug-fixes through the following techniques:
- reduce dependencies - the less components that are linked to the code being changed, the less risky a change is.
- regression testing - A regression test will improve the likelihood of discovering breaking changes. Regression tests can take many forms - anything you run daily, (or at the same time as your builds) is a regression test. This includes NUnit-style unit tests, and FIT tests.
- Code reviews - part of a bug-fix code-review can be to review the impact of the change. Any tool that shows coupling (such as NDepends) can probably help with this.
- Impact analysis - Pre-identify parts of the system that others depend on heavily. Changes in these parts of the system are particularly risky and need careful attention.
3 comments:
I'd have to say it was the other way around. If your design is solid then the impact of any change is localized. Not only that, but it is also easily understood. You can look at the code and accurately predict the change in behavior to the system. You can devise a simple short test to verify that the change worked.
If the impact of making a change is 'undetermined' that generally implies that the the logic in the code is extremely complex; usually more complex than necessary. The side-effect of that is that making the change is risky because you can no longer predict the effect.
Often I'll use the term 'bug' as widely as possible to mean any change to anything in the system (new or old) because the original behavior was undesirable. In that sense, typos on the screen are included. If it is not a multi-language system, there should be no side-effects (accept possibly screen inconsistencies) from fixing a typo, so there is no risk to making that change. You could release the system with minimal testing, just a visual check to make sure the change was actually done correctly.
It's all relative. Yes, overall it is less risky to fix bugs in a well designed system than it is in a poorly designed system. The point is more that in a poorly designed system (the norm), you can treat bugs and new features almost on equal grounds - they are both risky. In a well designed system, bug-fixing is the more risky activity.
How is this important? One example that comes to mind is that when a new team member joins a project, we will assign them to fixing bugs. In a poorly designed system, this is a justifiable choice, because the newbie is going to be breaking stuff anyway, whether they work on something new or existing.
Contrast with a well designed system, where the case for them working on new functionality is much stronger, because the risk of assigning newbies to bug-fixes is high.
I agree with steve campbell above. I have seen it go both ways but on a particularly well designed application I worked on in 2003 they assigned me to fix ALL the bugs. The reason was they didn't trust anyone else to do it right without breaking things so they stuck the lame developers on NEW functionality. The problem with that is though that they are just continuing to create bad code and I am constantly following behind their new development with my bug fixing pooper scooper. Instead if I was assigned to the NEW development there wouldn't nearly be as many bugs. Its a catch-22!
Post a Comment