[gruseom]

What is saved in the source code is less important than what is stored in the brains of the people who wrote it.

Very much so. The classic articulation of this is by Peter Naur (the N in BNF) in his 1985 paper "Programming as Theory Building". A software system is a set of concepts ("theory") residing in the minds of the people who build it. Source code is a lossy expression of this.

I often wonder would come out differently if one took that insight as a starting point for organizing software work and rigorously followed its consequences regardless of convention.

[6ren]

Thanks, sounds like exactly my perspective. google viewer version of Naur's paper https://docs.google.com/viewer?url=https://blog.itu.dk/SASU-...

People have tried to put more of the theory into the source e.g. literate programming. UML and design patterns can be seen as a (not entirely successful) attempt at this.

Crucial to a "theory" is the "data". A test-suite can record this data, suggesting that tests need not only be about the software (or testing it, or documenting it), but also about the problem.

On theories: Sometimes when a project expands in scope, a different theory is needed. Not to cope with the greater load, but to interpret it differently - like how uncropping an image can reveal a different interpretation.

[gruseom]

Things like better documentation and diagrams are bound not to suffice if Naur's view is correct that the program lives in the minds of the people who build it. To say, "Oh, the source code doesn't tell us everything, therefore we'd better produce additional documents that do," misses that point.

The best contribution I know of that works well with Naur's idea is Eric Evans' concept of ubiquitous language.