Contents
There will be code
One might argue that code is no longer the issue; that we should be concerned about models and requirements instead. Nonsense! We will never be rid of code, because code represents the details of the requirements.
I expect that the level of abstraction of our languages will continue to increase. I also expect that the number of domain-specific languages will continue to grow. This will be a good thing. But it will not eliminate code. Indeed, all the specifications written in these higher level and domain-specific language will be code!
Bad code
Have you ever been significantly impeded by bad code? If you are a programmer of any experience then you’ve felt this impediment many times. Indeed, we have a name for it. We call it wading. We wade through bad code, hoping for some hint, some clue, of what is going on; but all we see is more and more senseless code.
The total cost of owning a mess
Over the span of a year or two, teams that were moving very fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two or three other parts of the code. No change is trivial. As the mess builds, the productivity of the team continues to decrease, asymptotically approaching zero.
Why does good code rot so quickly into bad code? We have lots of explanations for it. But the fault, dear Dilbert, is not in our stars, but in ourselves. We are unprofessional. It is unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes. You will not make the deadline by making the mess. Indeed, the mess will slow you down instantly. The only way to make the deadline — the only way to go fast — is to keep the code as clean as possible at all times.
Being able to recognize clean code from dirty code does not mean that we know how to write clean code! Writing clean code requires the disciplined use of a myriad little techniques applied through a painstakingly acquired sense of “cleanliness.” This “code-sense” is the key.
School of thought
Many of the recommendations in this book are controversial. You will probably not agree with all of them. You might violently disagree with some of them. We have learned them through decades of experience and repeated trial and error. So whether you agree or disagree, it would be a shame if you did not see, and respect, our point of view.
We are authors. And one thing about authors is that they have readers. Indeed, authors are responsible for communicating well with their readers. The ratio of time spent reading versus writing is well over 10:1. We are constantly reading old code as part of the effort to write new code.
The boy scout principles
It’s not enough to write the code well. The code has to be kept clean over time. If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot.
| Previous: Forward & Introduction | Up: Contents | Next: 2 Meaningful Names |