by Ash White / 01.13.10
I've finally gotten around to picking up a copy of The Mythical Man Month, a collection of essays on software engineering written by Frederick Brooks which was originally published in 1975.
While the majority of the book has stood the test of time remarkably well, Chapter 3, entitled "The Surgical Team," especially intrigued me. The essay draws an elaborate analogy between a team of software engineers and - you guessed it - a surgical team. Brooks proposes that splitting large groups of coworkers into multiple smaller chunks based on the following positions:
- The Chief Surgeon is the lead developer of a group, responsible for all coding, testing, and documentation of a system or sub-system.
- The Copilot is the surgeon's assistant, whose job is to act as a sounding board for ideas and to know the code like the back of his hand to provide support when needed.
- The Administrator manages the team in addition to keeping an eye on the group's finances and resources.
- The Editor is responsible for managing and editing the documentation generated by the surgeon.
- Two Secretaries provide support for the administrator and the editor to assist with correspondence and non-critical project files.
- The Program Clerk manages the records of the project, namely documentation and source code.
- The Toolsmith assists the surgeon by crafting specialized tools as needed.
- The Tester maintains test cases for evaluating the work produced by the surgeon.
- The Language Lawyer is a very specialized consultant-type who is responsible for using his deep understanding of the technologies being used in order to maximize the efficiency of the operation.
Ten people to work on one system or a part of a system? Isn't that a bit of overkill?
While the roles of the Surgeon, Copilot, Administrator, Editor, Secretary, and Tester are still alive and kicking, the Program Clerk, Language Lawyer, and Toolsmith have largely been replaced by the software that has been developed in the 35 years since the original writing.
The need for Language Lawyer has been mostly replaced by highly-optimized compilers, lightning fast interpreters, and next-generation hardware.
The Toolsmith can probably be largely replaced by free libraries available from services like GitHub and SourceForge (and in the special cases that require this role the surgeon could most likely fill it).
Additionally, some of the surviving roles probably are not necessary 100% of the time, in that team members can easily take on multiple roles. For instance, free tools like Dropbox and Google Voice mean that two secretaries (or even one) might not be necessary for smaller firms that don't need to spend a lot of time on correspondence. I don't think I've ever heard of or seen an ad for a position that consisted solely of testing other peoples' code. How much revising of documentation is there really to be done (that can't be sent to a wiki and delegated to junior developers)?
While I certainly agree that a pragmatic distribution of roles and a sensible partitioning of tasks are essential to a successful software development company, I tend to think that it's equally (if not more) important to consider how peoples' personalities affect the mix rather than what it is they do. I would much prefer working alongside a developer who produces 10% more bugs — but who is consistently enthusiastic, personable, and stimulating — than an emotionless savant or a pretentious guru. Spending a few extra minutes in code review is worth it when the offender contributes positively to the overall motivation of the team. Deodorant helps a lot, too.
I'll be interested to see how upcoming advancements in software and hardware continue to affect all of the surgical team roles. Here's to hoping that some rockstar developer doesn't write a piece of software that makes me as obsolete as OS/360.