Perdonatemi, ma...
It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don't have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a development project than bad code.
Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down. tiem and time again I have seen teams grind to a crawl because, in their haste, they created a malignant morass of code that forever thereafter dominated their destiny.
Of course bad code can be cleaned up. But it's very expensive. As code rots, the moules insinuate themselves into each other, creating lots of hidden and tangled dependencies is a long and arduous task. If you made a mess in a module in the morning , it is easy to clean it up in the afternoon. Better yet, if you made a mess five minutes ago, it's very easy to clean it up rigt now.
So the solution is to continuously keep code as clean and simple as it can be. Never let the rot get started.
Chapter 14: Successive Refinement - Conclusion - pag. 250Ricordate quando tante volte abbiamo ripensato al passato e ci siamo chiesti "Ma perchè abbiamo fallito?". Personalmente aggiungo questa qui: non sappiamo scrivere codice pulito.
