In the result of an external quality audit for a company that I know, I read the following sentence in the improvement section:
Very successful implementation of a development philosophy that favours the definition of requirements and the test phase rather than the fixing of bugs.
Hey! But a rule from Pragmatic Programmers reads like this:
Rule #2: Fix broken windows
The concept of Broken Windows come from the criminological theory:
Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters.
In software development, broken windows are bad designs, wrong decisions or even poor code. If you don’t fix them as you find them, you’ll end up quickly with software rot.
Uhm… Max Kanat-Alexander (of Code Simplicity fame) also says:
Not only… it also says that, when you solved the issue, you are supposed to make it never came back!
When solving a problem in a codebase, you’re not done when the symptoms stop. You’re done when the problem has disappeared and will never come back.
It’s very easy to stop solving a problem when it no longer has any visible symptoms. You’ve fixed the bug, nobody is complaining, and there seem to be other pressing issues. So why continue to do work on it? It’s fine for now, right?
No. Remember that what we care about the most in software is the future. The way that software companies get into unmanageable situations with their codebases is not really handling problems until they are done.
There is something I don’t really understand about these quality audits…
