Rule of Modularity

In his book The Art of Unix Programming[^] Eric Raymond proposed the Rule of Modularity.

Quote:

Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging complex code that is complex, long, and unreadable.

The Rule of Modularity is at the heart of Object-Oriented Design. Decomposing complex problems into a succession of smaller and more comprehensible problems which a human brain can reason about. Abstraction and encapsulation are fundamentally ways of managing complexity, and both have their roots in the Rule of Modularity.

The human brain is not yet evolved to tackle complex problems head on. A brain that was originally wired to hunt and build simple tools continues to struggle to fathom the complexity at the heart of software development.

The Rule of Modularity and the book from which it is derived is as relevant today as it was when first published over a decade ago in 2003. The book describes many of the ideas and wisdom from the early, pioneering days of computing dating back to the late 1960s and distills them into a book that is applicable to modern software development.

Software development is concerned with solving problems, and these can often be big, complex problems. Ultimately this means managing complexity. It shouldn’t be in the least bit surprising that any mechanism that allows a human brain to manage this complexity should continue to be so successful.