Chief Programmer Teams

I found an ancient programming book: Top-Down Structured Programming Techniques by Clement L. McGowan and John R. Kelly (1975). It describe Harlan Mill's project at IBM where he pioneered CPT. Guess what. It worked. These reasons for success are easier to see from an agile perspective. Early 70s software development was primitive. The existing paradigm structured programming seemed solely concerned with control flow. Avoiding spaghetti logic is a good thing. But what about data? No talk about global variables, and how to avoid them. Also no talk of data structures, design patterns, module dependencies, or frameworks.

CPT's good features

• Code centric. Unlike later methodologies that became focussed on design artifacts such as diagrams and object models, CPT was focused on code. Good clean readable code accessible to all team members.
  

• "Automated" development environment. In the sense that programmers were supposed to focus on programming and a librarian (human being) managed builds, test runs, source code control, and backup. This also promoted early integration of all code (avoid Big Bang System Integration nightmares). And buildable-code every day.
  

• Top-down programming. write top level code and wrote stubs for lower level. So module M would be written with all lower-level modules that it calls stubbed out. This led to 'buildable code every day' and some sort of testing.

• "structured programming" approach promotes abstract thinks. The topmost levels consist of fn calls to lower levels. In order to understand the top level you really need to understand what each subsystem call does -- its contract.

• Chief Programmer does the design. Other methodologies split design work out across sub-system teams, leading to inconsistencies in naming, approaches, and quality.

• promotes metrics ('development accounting'). #bugs, #builds, LOC

CPT has some bad things

CP is supposed to be many things:

• senior-level programmer
• experienced professionals
• highly skilled in analysis, spec, design, coding, testing, and integration
• capable of managing a team (cost, time, resource requirements)
• capable of working with senior management
• capable of working with the customer

There is no talk of prototyping. Top-down programming really requires that you know where you're going. You're supposed to decompose and decompose. What if you reach a lower-level and realize that a module is impossible or impractical to implement?

Top-down assumes monolithic software where the programmer has control of main() and the entire application stack. And indeed in the old days that's exactly how it was. Modern systems are event-driven, loosely coupled, and cross multiple technology boundaries. A user browses to a web site, whose server-side code invokes a web service, that updates a DB, that has a db trigger, and queues a job request in MSMQ, that generates some content, that notifies 'subscribers' using RSS. The programmer relies on the underlying platform to connect these pieces up using mechanisms and interfaces of the platform's (not by the programmer's) choosing.


All in all, CPT reminds me of open-source programming Linus Torvalds-style, pre-Internet where everybody is in one room.