6. Passing the word

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

The question this chapter tries to answer is “how shall the manager ensure that everyone hears, understands and implements the Architect’s decisions?”

These are the suggestions of Frederick P. Brooks:

1. Use precise, full and accurately detailed written specifications;
2. Weekly half-day meeting of all the architects. The chief Architect presides. Problems and solution proposals are presented and discussed. If a consensus emerges, well and good. If not, the Chief Architect decides. Written summaries are kept and formally, promptly and widely disseminated.
3. As time goes by, a backlog of discussions builds up. To solve these and keep a clean backlog we should have a meetings period (1 week?) every few months (6 months?). These meetings can include the Architects and developers, but also managers and even marketers.
   • Personally, I would rather have a clean agenda policy, so that any issue can be discussed and solved ASAP, preventing the creation of code that could need refactoring once the discussion is actually held.
   • Also at a personal level, I find it very useful to have periodic meetings (6 months) to communicate the product vision to the technical leadership (Architects and Lead Developers) so that the Product vision and the technical vision are aligned. This can prevent the creation of code that might need refactoring after a few months because future product needs were not taken into account.
4. As implementation proceeds, questions are made to the Architect(s), by the developers… All the relevant thoughts triggered by these informal discussions should be recorded in a log, concatenated with other Architects’ logs and distributed to all stakeholders.
5. Continuously testing the application is a way to make sure everyone keeps to the specifications. Back in 1974, when the book was initially published, the advice was to have a testes team, but my experience is that nowadays its both cheaper and more reliable to have automated testing developed simultaneously, by the developers, during the implementation of the features. Nevertheless, I can’t overrule the need for a specialized team in projects with special needs.