Okay, so if we never change our software, we can entirely avoid defects. But change is inevitable, particularly if we’re going to add new features. So “don’t change anything” can’t be the ultimate defect reduction technique.
As explained in Chapter 5, if you want to avoid defects in your code, it does help to keep your changes small. But if you want to go further and eliminate defects even from your small changes, there’s another law that can help you. And it doesn’t just reduce defects—it keeps your code maintainable, makes it easy to add new features, and improves the overall understandability of your code. This is the Law of Simplicity:
The ease of maintenance of any piece of software is proportional to the simplicity of its individual pieces.
That is, the simpler the pieces are, the more easily you can change things in the future. Perfect ease of maintenance is impossible, but it’s the goal you strive for—total change or infinite new code with no difficulty.
You may have noticed that this law doesn’t talk about the simplicity of the whole system, though, only the individual pieces. Why?
Well, an average-sized computer program is so complex that no human being could comprehend it all at once. It’s only possible to comprehend pieces of it. So we actually always have some large, complex structure for our whole program. What then becomes important is that the pieces can be understood when we look at them. The simpler the pieces are, the more likely it is that ...