According to Wikipedia, “a chief programmer team is a programming team organized in a star around a “chief” role, granted to the software engineer who understands the system’s intentions the best. Other team members get supporting roles.” Amusingly, this set-up is alive and well in academia, and for good reason. At least my research group is using it and it works well for us.
In its original definition by Harlan Mills, this rather old approach to software development has a differentiated set of roles all supporting a central engineer, the chief programmer, in developing the system. In our more modern incarnation, we still have a chief programmer, a Ph.D. student, who develops some software part of his or her dissertation and in our case often with an eye towards a startup. Because the software might become the foundation of a startup, my Ph.D. students care deeply about the engineering quality of their work and tend not to develop throw-away research prototypes.
Unlike the original definition, we don’t need many different roles. For one, the engineering progress around agile methods has obviated much of the need for separate testing. We don’t need a “language lawyer” either. Nor a secretary or program clerk or tool smith. If you will, we only have “backup programmers”, which are simply junior programmers to the chief programmer. I’m talking about Bachelor’s or Master’s students who want to write an engineering thesis to finish their degree program.
The chief programmer has oversight of the system under development. He or she delegates smaller and larger pieces of work to students, either for their final thesis or as part of a student job. In all cases, the supporting programmers are transient, which is probably the core reason why the chief programmer idea works in academia: The centralization of knowledge in a chief programmer ensures continuity and quality over longer time spans than the six months that a final thesis student might be contributing to the system.
Next up: How the chief programmer interacts with supporting students, the agile tools that work, those that don’t, and more.