[1/2] The Mythical Man-Month (The mythical man-month) (Category Management)

This book by Frederick Brooks was first published. 50 years ago, in 1975 It is still being reprinted, and the quotes from it have become classic. I decided to remember it for the anniversary and see how relevant it is.

The title of the book contains the idea that "Adding staff to a lagging project only increases delaysdue to increased communication costs, time to adapt new team members and the indivisibility of some tasks. Brooks criticizes erroneous assumption that labor (man-month) You can scale it linearly, comparing it to the inability of nine women to have a baby in one month. This applies to project/product management and is as relevant as it was. 50 years ago. It also emphasizes the importance of conceptual integrity A coherent system architecture led by a single vision to prevent chaos caused by committee-assisted design. This thesis applies to software design. The following key idea relates to “second-system" (complexity when creating the next version). This problem seems to have been solved, since products are often built iteratively and the concept of a system version is blurred:) The last thing to note is the difference between essential complexity (significant complexity inherent in the task) accidental complexity (Accidental complexity caused by inefficient tools or processes).

If you draw parallels between development in Brooks' time (1970-e years and mainframe dominance)Then we get the following.

1) Brooks' Law vs. Agile and Hybrid Work Agile approaches reduce the risk of surprises, and even by working with design, we get less risk in the later stages, which corresponds to Brooks’ thoughts about the importance of prototyping in large projects. Hybrid work - modern tools (GitHub, Jira, Slack) reduce barriers to communication, but the rule about the quadratic increase in communication costs from the growth of the team does not go away (Remember that in the full graph n*(n-1)/2 linkage) Brooks recommended using localized "surgical teams," and we now have two-pizza teams. 2) Modularity and wet services Brooks was worried about the monolithic system that they were doing for the mainframe, but in our time, we have SOA, microservices, FaaS and now people do not think the monolith is such a bad option to start. In fact, we need the modularity of our code, and how it unfolds can be solved later. (conditionally modular monolith can normally be divided into separate microservices if necessary.) 3) Tools against the human factor

• One of Brooks' key thoughts was that there was no silver bullet to improve productivity. But what we see is that good engineering practices have gradually increased the productivity of engineers -- CI/CD and automation. And now we live in a time when a pinch of AI added to SDLC (software development life cycle) GitHub Copilot promises big impact in the future (If the LLM continues to progress) But while we still see AI as an assistant, which means we need to pay attention to the human factor, there's a cool column about Google's "Human approach to developer productivity" that I'm already talking about. beforehand

Continuation of the review in next post.

#Management #Leadership #Software #Engineering #Process #Project #Architecture #DevOps