Software Engineering discussion

This chapter, although quite dated, is the source for the oft-quoted 10x disparity in programmer productivity in the marketplace. What most of the quoting publications miss is Brooks' associated discussion about the difficulty of effectively harnessing a group of superstars for large projects. Communication, coordination, and change problems don't disappear with a team of superstars. Ego clashes are a big problem too. Although some managers dream of a team of superstars as the software engineering development magic bullet, in reality a proper balance of team skills is more important, beyond small projects.

However, the specific division of labor advocated in this chapter is extremely dated. I have never seen a project organized in this way. We need to harken back to the era of typewriters, carbon paper, batch jobs, and line printers to appreciate this advice. Although obsolete, it is interesting to reflect on how far we have come in some areas (language lawyers, large amounts of secretarial support), and how little progress we have made in others (testing). Only the final paragraph in this chapter hints at a more modern division of labor, between architecture/design and implementation.

Yes, the specific duties listed for each role were very dated. I had to think pretty hard to imagine exactly what some of those tasks might entail.

Some of the ideas still show up in modern teams. I think the Scrum Master, Scrum of Scrums, Product Owner, etc... are similar to some of team roles and concepts listed in this chapter.

I noticed several of the roles in this chapter were not actually writing any code. I was surprised by that, but I understand the reasoning. I have mostly small company experience and a lot of the perceived overhead roles (secretary, tech writer, etc...) are skipped (or cut).

The 10 person group is still close to modern group sizes too. I think scrum likes about 8 people per group maximum.