Over at ye ole Salon we find a somewhat ramblerific article on software evolution which pretends it's mostly about "Meir 'Manny' Lehman", apparently the first guy to do a paper on software evolution, in his case OS/360 at IBM.

Ole Manny apparently came to the following conclusion:
OS/360 was heading over a cliff. IBM, in stressing growth over source-code maintenance, would soon be in need of a successor operating system.

IBM reportedly ignored his report, but 3 years later were splitting OS/360 into two more manageable branches.

The bottom line of Manny's theory, which is apparently relatively hotly disputed in the right circles, is that software tends to grow in a curve that's the inverse (I think... been a while since I had geometry) of Moore's law (which has processor power growing at a geometric rate). The blame seems to be laid at the feet of programmers, who'd rather add something new than test something old, making larger software projects grow into a more chaotic system, in a fashion, when it comes to "bugs over time". In other words, any program that's been around long enough, unchecked, left to software developers' own devices, " all software programs are ultimately doomed to succumb to their own internal inertia" (From Frederick P. Brooks' "The Mythical Man Month", quoted by the above article, and reportedly based on ole Manny's work). Without adding energy to the system, in a sense, specifically for the removal of this chaos, software development produces poorer progress per unit of work added over time.

That software developers like to add new instead of understanding old isn't a new idea. Old man Joel has said something similar about refactoring code instead of rewriting it. Strangely, though, it would seem that keeping old code, according to Manny, would make it so that keeping this old code puts you on a one way course towards "succumbing to your own inertia", so to speak.

I'd guess Joel's response would be that most people aren't working on OS/360 or a likeminded project, and that you're generally much better off keeping what you've got [and the lessons the code's already learned]. There's also the obvious possibility that we're talking apples and oranges -- developers would prefer to add something new than to fix something old, which I believe is a complaint of the open source software movement (that things are added all the time, but not well-tested).

But the apples and oranges arguement aside, it would seem that if there was only a system where many programmers could add their "fresh, new, inertialess" code to a living whole, you wouldn't find yourself smacked on the head by the continually more complicated vortex products like [traditionally created] operating systems or Microsoft Words possibly produce.

Hrm. That process sounds familiar, doesn't it?

Another poorly edited ramble by ole Rufbo there.