Chief Programmer Team

The team structure described by F.T. Baker as used on the New York Times project conducted by IBM. His article, Chief Programmer Team Management of Production Programming, was published in the IBM Systems Journal in 1972.

Can you spot the weak links in that design?

No, I can't, because the image doesn't show it.

The weak link is the one between 'Problem' and 'Solution' which consists of 'Chief Programmer'. We know this is the weak link. That's why it's reinforced with librarian, secretary, lawyer, tester, co-pilot, etc. It relies on the chief programmer knowing that he is unable to solve the problem; it relies on his ability to ask for when when he needs it (which will be always). But it doesn't rely on everybody on his team having the same (although it helps). If you're worried about errant trucks, hire a bodyguard as well :p --WilliamUnderwood (who also considers himself to be an XP zealot).

I was reminded of this book/project when I first encountered XP -- I wonder if both just suggest that the key to system development success is finding a very competent technical lead and staying out of his/her way! --JimRussell

An XP team practices CollectiveCodeOwnership and XpDesign. There is no technical lead per se. The OfficialXpPersonnel do recommend having a coach. However, the coach does not act as the chief or architect. He is a resource for the team, which does all the work and makes their own decisions. --DonWells

The Chief Programmer has to be both technically competent and well rounded: There are plenty of technically skilled people out there who (#1) will tend to over-complicate the problem and/or (#2) have poor people skills. -- JeffGrigg

In some super-big mega-buck aerospace projects, there was only one guru hothead available in the entire world who could anchor the project. The team arose around this chief to employ cheap braves to relieve his workload. These projects so often naturally assumed a CPT configuration that the practice was hallowed as a "best practice" by those whe didn't know any better.

Also, because a TruckNumber of one was generally recognized as bad (back in the days when the Truck could actually be commie agents kidnapping your guru), the role had an understudy. The above diagram calls this role the "co-pilot". --PhlIp

FredBrooks describes a similar setup in The MythicalManMonth, which he attributes to Harlan Mills' paper, "Chief programmer teams, principles, and procedures," in the IBM Federal Systems Division Report FSC 71-5108. Brooks' characterization has no grunt programmers. He also includes a "program clerk" who "is responsible for maintaining the technical records of the team...and has responsibility for both machine-readable and human-readable files." He also says that the administrator and the language lawyer can be shared between two or more teams.

Under this conception, the truck number is two, by my count, which isn't bad when you only have two "real" programmers. The toolsmith might have some secret knowledge, but his disapperance should only slow the surgeon down, not stop the project, until a new toolsmith can be spun up.

In a modern interactive computing and business environment, I would suspect that the secretaries and program clerk would more or less go away, and the administrator would be more broadly shared than in Brooks' conception.

Also note: Since this time, the programmers have been replaced by compilers, because of higher level languages. And the librarian by a revision control system and policies.

Does that just leave a chief and co-pilot. I would like it if they where more equal.

CPT happens all the time in the field. Imagine a good programmer but excellent politician exploiting a local power vacuum to personally build a large team of low-wage grunts, instead of any real programmers who could kick her or his butt. He thinks he's saving time typing; he's reinventing a failed pattern and setting a department up for the results.