- A lot of work you thought would take 1 day ends up taking 1 month because most of the code you reuse is leaky, which causes unforeseen extra work.
- You get annoyed that your plans and deadlines are actually worthless with this type of low quality code base. You get so irritated that you want to do something about it.
- You start to make a list about possible refactorings that would increase the robustness of existing code. You add items to this list whenever you see something fishy in code, but you can't act on it right away because you almost certainly have some crisis that needs fixing immedately.
- Whenever there is a break from firefighting mode, you go back to your list and start working on the most important items.
- You realize that most of your refactorings will have unforeseen side effects and that you have to revert them. You give up refactoring at this point and go back to firefighting.
- After wasting 10 years, you realize that you have to refactor on the off chance of improving quality to the point where you can reuse code in peace. And you are enlightened (!)
A novice programmer was once assigned to code a simple financial package. The novice worked furiously for many days, but when his Master reviewed his program, he discovered it contained a screen editor, a set of generalized graphics routines, and an artificial intelligence interface, but not the slightest hint of anything financial. When the Master asked about this, the novice became indignant. "Don't be so impatient," he said, "I'll put in the financial stuff eventually."Notice that I have not mentioned any software development standards or processes. Their time comes after you have matured through these phases. The most important one is phase 2, i.e. to be annoyed of wasting time by not being able to trust existing code, ending with rewrites whenever you "reuse" code.
Music: Kraftwerk - Das Model
