Rule of Modularity

As Brian Kernighan once observed, “Controlling complexity is the essence of computer programming.” .
Debugging dominates development time, and getting a working system out the door is usually less a
result of brilliant design than it is of managing not to trip over your own feet too many times.

Assemblers, compilers, flowcharting, procedural programming, structured programming, “artificial
intelligence”, fourth-generation languages, object orientation, and software-development methodologies
without number have been touted and sold as a cure for this problem. All have failed as cures, if only
because they ‘succeeded’ by escalating the normal level of program complexity to the point where (once
again) human brains could barely cope. As Fred Brooks famously observed [Brooks], there is no silver
bullet.

The only way to write complex software that won't fall on its face is to hold its global complexity down
— to build it out of simple parts connected by well-defined interfaces, so that most problems are local
and you can have some hope of upgrading a part without breaking the whole.