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, l ooking 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....