Software is People
battlehardened.wordpress.com
battlehardened.wordpress.com
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.
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.
The best contribution I know of that works well with Naur's idea is Eric Evans' concept of ubiquitous language.
But unlike the executables, our source code is designed for humans to read, and only incidentally for machines to execute. When important information is hidden away in design documents and our heads, the code slowly changes from an orchard into a minefield. When you need to ask someone how something works or how to change a module rather than glance at a few lines or diagrams, we begin to lose our status as masters, and become trespassers. When we entangle our code, we entangle ourselves.
As programmers, we strive to put our souls in the code, making it a timeless artifact that can stand on its own. Creating software that can live apart from its creators is an ideal that few reach, but it is necessary if we wish to avoid spending a lifetime on child support.