As mentioned in a previous blog post, my Ph.D. students are often experienced software developers who take on the role of a chief programmer in the development of the software system supporting their research. In this work, at any point in time, each of my Ph.D. students is typically supported by 2-7 Bachelor and Master students who contribute to the system under development. Taking a long-term perspective, my Ph.D. students develop quality software rather than throw-away prototypes.
The chief programmer idea is key to making such work successful. While I usually conceive and direct the research, the size of my group has led me to let my Ph.D. students take care of any actual development themselves. (Usually…) In this role, as the chief programmer, they become the central point of coordination and integration of engineering work. In academia, this is a necessity, because an engineering dissertation is typically a multi-year project, while final thesis students, the main source of junior programmers supporting the chief engineer, are only around for six months. Thus, the chief programmer becomes the central technical hub and provider of sustained knowledge of the system under development.
In this role, the chief programmer delegates work to students. We use a Kanban board to plan and assign work. Final thesis students each get assigned a major feature, and the chief programmer breaks it down, initially, for the student, until they learned to split features into tasks themselves. Some students can do this sooner than others. Some are more capable than others. For this reason, we don’t use time-boxed iterations but rather follow the flow of Lean and the support that a Kanban board gives us. This, way students are also decoupled from each other. Such delegation of work allows for both feature as well as component-oriented programming, as the chief programmer can serve as an efficient oracle when questions arise about how to integrate a feature into the code base.
Next to coordination and delegation, integration is the main other job of the chief programmer. My Ph.D. students tell me they can work with up to seven Master students at any one time. At this load, all my Ph.D. students do is integrate their Master’s students work. Using pre-commit code review, they engage in a constructive forth and back with their students until the code contribution is right and ready. This is very much like open source distinguishes committers (my Ph.D. students) from contributors (our Bachelor and Master’s students).
Next up: What to do if you have multiple chief programmers (i.e. a research team) or whatever question you might have about this set-up.
Leave a Reply