The Mythical Man-Month

The Mythical Man-Month

Today we re-read the fourth essay in The Mythical Man-Month titled: Aristocracy, Democracy and System Design. In this essay, Brooks deals with the role of conceptual integrity in building systems and the impact organizationally of getting to an appropriate level of conceptual integrity. According UC San Diego, conceptual integrity is the principle that anywhere you look in your system, you can tell that the design is part of the same overall design. Brooks suggests that conceptual integrity is most important consideration in system design. He begins the essay by building the case that conceptual integrity leads to high ease of use, and therefore higher value. Systems with conceptual integrity have one set of design ideas and that ANY idea or concept that violates conceptual integrity must be excluded. Conceptual integrity is important because systems that are based on any different architectural concepts are both hard to work with and maintain.  For example, many of the houses in my neighborhood began life as lake cottages. Many of these cottages have been added to over the years in a fairly haphazard manner. Over the last few years many have been knocked down due to high cost of upkeep that their complexity generates. Software systems are no different; complexity leads to increased support costs, bugs and systems that are hard to use. In Aristocracy, Democracy and System Design, Brooks addresses three questions (he posits four, but postpones the discussion of the fourth until the next essay):

  1. How is conceptual integrity achieved?
    Brooks addresses this question from the point of view of a programing system. The goal of a programing system is to making using a computer easy. You could easily substitute any other type of system or application for the term “programing system”. Brooks argues that the goal of ease of use dictates unity of design, therefore conceptual integrity.  Ease of use can’t exist if the design consists of disparate ideas that make the system both less simple and less straightforward.
  2. Doesn’t unity of design imply an aristocracy of architects?
    Brooks suggests that conceptual integrity in design comes from one or the collaboration of a small set of coordinated minds. Unfortunately constraints like schedule pressure require organizations to use many hands to develop, design and build a system. There are two fixes to the schedule constraint. The first is the separation of design and build resources. Architects develop the design in advance of the developers. The architect acts as the user’s agent, developing a description of what is to happen. The developers in an implementation mode define how the whats will be constructed. The second solution is to use a surgical team. The surgeon defines how the operation will be done and then directs the operation.  The surgeon is the single person that controls the flow work and is responsible for the outcome. In any project the number of architects will always be less than the developers or testers therefore they will be viewed as aristocrats.
  3. What do the implementers do while waiting for the design?
    When organizations separate design and implementation, there are complaints because of the perception that the process yields:

    1. A scenario in which an overly rich architecture that can’t be implemented in the constraints most projects operate within. Brooks admits that this complaint is true and indicates that he will address it in the essay: The Second System Effect. In my experience, many organizations use standards, peer reviews and time boxing to combat this problem.
    2. A scenario in which developers have no outlet for their creativity.
      Brooks says this is a false argument. In my experience, even in organizations with the strictest architectural and design constrains, developers have wide latitude to be creative. That creativity is applied in determining how to implement the design within the boundaries and constraints they are given.
    3. A scenario in which developers will have to sit around waiting for the design to be developed.
      While Brooks says that this is a false argument, in my experience it is partially true. In scenarios where designers and developers are separated there will be some timing considerations. The Scaled Agile Framework Enterprise (SAFe) addresses this issue by developing an architectural runway for the developers. Just enough design and architecture is developed ahead of the development teams to provide the guidance they need just before they need it.

Conceptual integrity is an important concept that affects how any system will be developed. Brooks links higher levels of conceptual integrity to improved ease of use, productivity and maintainability. However the old bugaboo of schedule pressure, along with the perception that scenarios in which developers are sitting on their hands or are stripped of their creativitiy makes the pursuit of conceptual integrity difficult, but not impossible.

Previous installments of Re-Read Saturday for the The Mythical Man-Month

Introductions and The Tar Pit

The Mythical Man-Month (The Essay)

The Surgical Team