The Mythical Man-Month

The Mythical Man-Month

Sharp Tools is the twelfth essay of The Mythical Man-Month by Fred P. Brooks. Brooks begins this essay with a discussion of a development environment where each person has his or her own tools. Tools that were either handcrafted or acquired as thier career progresses. To the individual, this scenario feels efficient and effective; however at team or program level things are not as sanguine. Brooks likens developers to master craftsmen that develop their own tools in order to build works of art. Brooks wrote this essay from the point of view of his experience building operating systems, and when I re-read the essay I initially was unsure whether the message was relevant to the 21st century. However, reflection while jogging is a powerful tool for making connections. The relevance was brought home as I reflected on the time I spend with software development teams. People in these teams self-identify as coders, testers, business analysts, Scrum masters and even an occasional project manager. Each person assembles as set of tools and languages that they are comfortable using. Many of those tools are mandated by the organization or software platform they use. However, just as often development practitioners have accumulated open source tools, or even in some cases hand crafted utilities, over their career. In any practical sense the world described by Brooks is no different than it is today.

In a development project, the manager establishes the development philosophy and sets aside resources for the building of common tools. In today’s environment you might acquire a common toolset instead of building it; however, someone must provide guidance and direction. Many organizations feel the need to centralize tool decisions and then inform everyone involved of the toolset they will use. This type of decision process is often considered efficient (reasons can include central research and leverage in purchasing), but centralization often ignores the specialized needs of each team. Invariably this leads to team members sneaking in their own tools or doing work at home in less controlled environments. Brooks suggests a better answer is for each time to team have their own tool/environment builder guided by the program leader’s philosophy (Brooks used the term manager) rather than a central tool team. A community of practice based on the manager’s or organization’s philosophy delivers similar results using more current leadership philosophies. Again Brooks was ahead of the curve.

Regardless of whether you are involved in the development or enhancement of functional software you need access to an functional computer environment with a core set of tools.  Brooks identifies four basics that every software effort requires include:

  1. A computer facility with machines and a scheduling philosophy
  2. An operating system and service philosophy
  3. Language and a language philosophy
  4. Utilities

I will not belabor this re-read entry with a detailed explanation of each category. What is more important is that efficient and effective delivery requires an integrated environment where the target (production environment) and vehicle (development/QA environments) are closely related, and the right tools available to get the job done. Examples of organizations that still ignore one or more of these four categories abound. For example, teams trying to do Agile without tools to automatically test builds or adopting the concept of user stories without defining testable user acceptance criteria. The combination of environments, tools and processes based on a consistent philosophy is required to implement user stories and builds with automated testing.

When I began re-reading Sharp Tools I was concerned whether the message was still current. A discussion with a team about their adoption of continuous build and automated testing using Jenkins reminded me that 20th century developers and development teams that Brooks described are not materially different in nature from 21st century developers (Agile or waterfall). If we don’t have tools we are comfortable with close at hand, we find new tools. In order to work together in a team or a team of teams we need latitude to react within the constraints that a manager, architect or visionary provides as philosophy.

Previous installments of the Re-read of The Mythical Man-Month

Introductions and The Tar Pit

The Mythical Man-Month (The Essay)

The Surgical Team

Aristocracy, Democracy and System Design

The Second-System Effect

Passing the Word

Why did the Tower of Babel fall?

Calling the Shot

Ten Pounds in a Five–Pound Package

The Documentary Hypothesis

Plan to Throw One Away