I appreciate the idea of long-living teams (as opposed to disbanding after a feature or release), so when someone on VMware Slack mentioned Peter Naur’s 1985 essay “Programming as Theory Building” I had to bite. Some great arguments for long-living (durable) teams. Some notes to help my own synthesis.
- In a nutshell: a program is not its source code, but a shared mental construct that lives in the minds of the people who work on it. If you lose the people, you lose the program. The code is merely a written representation of the program, and it’s lossy, so you can’t reconstruct a program from its code. No amount of code commenting or documentation is sufficient to carry a program’s vital design ideas. Nothing can replace the knowledge of the team that is closely and continually connected with their codebase.
- New programmer joining? It’s not enough to become familiar with the source code, they must work alongside the team who possess the knowledge.
- A program reaches “death” when the original team is gone. A dead program can still be used and produce useful results, but its actual death becomes visible when demands for modifications “cannot be intelligently answered”.
- Can you revive a dead program? No. “reestablishing the theory of a program merely from the documentation, is strictly impossible”. If you don’t have the original team, throw away the code and start over, because you’ll likely still produce it at a lower cost.
- Programming methods that see programming as machine-like work hurt us even more, treating a programmer like an easily replaceable cog in the machine. “Theory Building View throws this out, saying the programmer has the mental possession and is not easily replaceable.”