Rule 10. Localize Complexity
Complexity is the enemy of scale.
You know that simpler code is better—as simple as possible, but no simpler, per Rule 1—but that Rule becomes harder to follow as the scale of your project increases. It’s easy to keep your code simple for simple problems, but as code grows and matures it naturally grows more complicated. And as it grows more complicated, it becomes harder to work with—you lose the ability to keep all the details in your head. Every time you attempt to fix a bug or add a new feature, you trip over unpredictable side effects—every step forward is matched by an unexpected step backward.
Part of the solution is to look for opportunities to keep things simple or make things simple. That’s Rule 1. But complexity can’t be eliminated entirely; any moderately functional and long-lived bit of software is going to have to weather the complexity inherent in the problems the software solves. But complexity can be managed.
To borrow a sports cliché: you can’t stop complexity, you can only hope to contain it.
Along those lines, a useful strategy is to isolate any complexity you can’t eliminate. If the internal details of some bit of code are complicated, but its external interface is simple, the complexity presents less of a problem. When you’re inside that bit of code you have to cope with its internal complexity, but outside the code you don’t have to worry about it.
A Simple Example
Consider the sine and cosine functions in your language of choice. ...