Two titans of software engineering disagreed with one ultimately conceding the argument. However, I found that resolution unsatisfactory. This is about David Parnas and Fred Brooks; software wouldn’t be where it is today without their contributions. Their disagreement involves ideas that have shaped modern programming techniques and open source. David Parnas wrote a paper on , a precursor to the notion of encapsulation. He compared two modularizations of a software system. In one, the design decisions and data structures were visible to the entire application while many of those were hidden in the second one. The second implementation was easier to understand and change. information hiding Fred Brooks penned the timeless classic: . It explains why adding more programmers to a project often doesn’t speed things up. It’s a result that is in part due to increased training and communication overhead but also because it is impossible to decompose a complex project into neatly separate independent tasks. Brooks drew his observations from the time he managed the development of IBM’s ground-breaking OS/360. One of the most interesting decisions in its development was that every programmer on the team had access to the entire code base. The Mythical Man Month Brooks called the idea of shielding programmers from code written by others a “recipe for disaster.” As Brooks explained, open access to the code was necessary because interfaces are rarely “completely and precisely defined.” So the disagreement was about the benefits of information hiding and the advantages of openly sharing code. In 1995, Fred Brooks conceded the argument in a section entitled “Parnas Was Right, and I Was Wrong about Information Hiding” in the revised edition of his book. So, why do I find this resolution so unsatisfactory? Hasn’t open source established the value of sharing code and don’t we need encapsulation? In my opinion, both were right, and the conflict is less real than it appears. Perhaps, the perceived disagreement resulted from a lack of collaborative tools and technologies available at the time. Far from being in conflict, I would assert that information hiding is critical to the success of openly sharing code. Today, we think of information hiding not as a programmer’s hidden code but as a call for encapsulation. The implementation details aren’t hidden from other but from other . Programmers come and go, but the code we write lives on. The onus is on programmers to write code that does not depend on the implementation details of other modules. Many languages now provide mechanisms that make it harder to create those unwanted dependencies. programmers programmers’ code Just as Parnas claimed a long time ago, today there is widespread agreement that well-encapsulated code which does not depend on the implementation details of other modules is easier to understand, use and maintain. The success of open source hinges on our ability to write code that others can understand and improve. These two seemingly opposite positions on information hiding and open access to the code are complimentary after all.
