[gregfjohnson]

The “software as theory” idea is helpful - thanks OP. Right now I’m dealing with some devilishly difficult GPU code, and I now understand that I’ve been working to reverse engineer the authors’ theory from their code. With much effort, I achieved a gratifying epiphany, and the code suddenly became clear! (Perhaps I developed a theory related to but not identical to that of the original authors.) Fortunately, I have an enlightened manager, and he was patient with the “theory building” process. Software degrades to garbage when a series of successive developers apply changes to it without a cogent theory. The process is self-reinforcing; the more degraded it becomes, the harder it is to develop a useful and accurate theory.

[jwhiles]

“ The process is self-reinforcing; the more degraded it becomes, the harder it is to develop a useful and accurate theory.” This is a really good point I think.

It feels like the Sprint / Agile practices that a lot of us use lead us to value expediency more than anything. So we'll try and find the quickest way to make a change that gets an existing program to do what we want. If we lack a working theory of the codebase that usually means we're doing something that runs counter to the overall design. And then over time everything gets worse and harder.