In one of my recent tweets I noted that I had been reading through Fredrick Brook’s The Mythical Man-Month again when the mind needs a break in the office. In between all of the dated, but fascinating, technology references there is plenty of gold to mine.
One of the striking organizational skills he goes over is the construction of a programming team. I have worked in plenty of different small-medium sized organizations, but I have never been involved in a genuine single-project group-development effort. It has been a single programmer working in isolation. Or, at best, two programmers splitting a project down the middle with a static and defined interface (this tactic is also described in the book).
Only now am I working in an actual group where roles are given. Some of Brook’s roles are: tool-master, architect, and specialist, and program manager. Obviously I don’t need a batch tape scheduler anymore – but the above roles are very key. The program manager represents the client and user interests. The architect represents the sole owner of technical implementation decisions. Now, in all the other organizations I’ve been a part of, these roles undoubtedly exist. There might be two or more people competing or fulfilling these roles – but they exist. What I had not previously experience was the tool-master and specialist.
The tool-master is solely responsible for creating the tools necessary for the team to do their jobs. I’ve seen this manifest as; deploy scripts, local environment tools to mock out production infrastructure, and using and contributing to open source projects (we do not suffer from NIH syndrom). Sometimes this person is me. Sometimes it is not. But the tool-master is always responsible for his tools and to keep them up to date, and to keep the team informed about how to use them. Without this last point members of the team are wasting time figuring something out that has already been done.
I have experienced the specialist to be one of the most invaluable assets to the architect. If the architect is responsible for the whole system and writing most of the code what happens when he or she hits a small thorny problem. Sometimes it is an incompatibility between two pieces of software, or server settings. But whatever it is, someone has to take the red pill and go down the rabbit hole. If your architect goes in, he’ll come out a couple of days later with the beginnings of a beard, and a solution, but features won’t have be written. It is crucial to have a specialist who can take these thorns that need fixing.
All in all the amazing discovery I am witnessing is the overall level of communication on a team that quickly figures out how to design, architect, and implement projects; figuring out the limitations and ways to solve and overcome them.


Android’s much ballyhooed 1.5 release (aka Cupcake) seems to be imminent. Last week, Google released a