Fred Brooks’ “The Mythical Man Month1” was one of my favorite books from way back when. His themes of the “Second System Effect” still ring true as often in corporate life a new system is introduced that will “fix all the bugs in the previous system” only to reveal a new set of problems that users have to live with. And the old rule of “Adding more programmers to a team makes a late project later” was also a true-ism. The Chief Programmer Team model, originally from IBM2, was also discussed by Brooks as a way to reduce the communication overhead of a larger team while working productively on a complex project. One key factor of this model is the support staff that work on the details of the project for the Chief Programmer.

The [Baker paper3] discusses the notion of a development support library (DSL) to speed up production by leveraging previously written and tested “machine code” that could be reused by the Chief Programmer. It also introduced the role of a “Programming Secretary” that helped, among other things, maintain the DSL.

Fast forward to 1981. The UNX movement was in motion, and I eagerly explored the UNX kernel and drivers through courses at Oregon State University. I even had a UNX “Live Free Or Die” coffee cup. And if you are a UNX Geek, then you get started with the “Command Line Interface”.

Programmer as Orchestra Conductor Images generated by Google Gemini

  1. Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. ↩︎

  2. Mills, H. D. (1971). Chief programmer teams, principles, and procedures (IBM Federal Systems Division Report FSC71-5108). IBM Corporation, Gaithersburg, MD. ↩︎

  3. Baker, F. T. (1972). Chief programmer team management of production programming. IBM Systems Journal, 11(1), 56-73. https://doi.org/10.1147/sj.111.0056 ↩︎