In a nutshell, to exemplify the idea that software development should fundamentally focus on knowledge acquisition (from the envirnoment the software will live in), and building problems frames (see Jackson) to inform the structure of the architecture (design), I sketched the following. It is simple, not powerfully explanatory, but it is the beginning of something I am working on. So don't shoot me just yet ;-)
Now, looking at some literature to further back up or challenge or enrich this idea, I came across this 1985 article by Peter Naur: Programming as Theory Building.
He says a programmer’s main activity isn’t coding, it’s creating a theory of the problem at hand and its solution. This theory is implicit knowledge, which can’t be written down.
Sure, I can transmit knowledge via documentation. But you can't understand my code as well as I do unless oyu acquire the theory I built in my head, and you can't get that by reading my docs or my code.
In other words, the actual code is not the point of programming ie the code is not an asset. Instead, the real goal of the software development team is to understand in depth the problem that they are trying to solve.
Comments