Slashdot Mirror
A Unified Theory of Software Evolution
jso888 writes "Salon has a nice article today on Meir Lehman's work on how software evolves and is developed. Lehman's investigation of the IBM OS/360 development process became the foundation for Brooks' Law: "Adding manpower to a late software project makes it later." He is hopeful that his work will make software development less of an art and more of an engineering science."
Manny Lehman is credited with coining the expression "Software Engineering". About 1968, I think. See also the website of the company he founded Imperial Software Technology .
it certainly seemed like the developers were just making random variations
This is called error seeding and is used to evaluate the performance of testing systems (including the people doing it).
On the other hand, I dimmly remember something about not to do it with production code....
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
I'm not sure whether this was supposed to be funny or whether other readers are interpreting it as funny. There have also been a few stabs at the parallels with life (evolution vs creation, etc). Hrm...whatever. From the article: "The gap between biological evolution and artificial systems evolution is just too enormous to expect to link the two,"
In all seriousness, I've seen so many project managers use evolution (not the theory explained in the article, however) as some sort of methodology for their projects and I have not seen any of those projects truely succeed. The idea that you throw something, anything, out there, find out what's good/bad with it, then re-iterate the design and development based on findings is such a random and expensive process. I've seen so many programmers put in half-assed functionality, especially on front-end code, just so that they'll let testers and "usability" experts fix the problem and fix it in the next release. This is like throwing a chunk of randomly chipped wood out and hoping that others can tell you how to sand it down to something usable.
Cooper makes this analogy in "The Inmates are Running the Asylum" (link here) and bashes project teams that take on this sort of process of evolution. He poses a process of almost completely up-front design by building to a theoretical user persona and culling out complexity by ditching features that will never be used by this persona.
Now Cooper's views don't necessarily contradict Lehman's (at least from what I've seen in the article). In fact at a glance they seem to blend in nicely.
From the article, again: Figure out how to control the various feedback loops -- i.e. market demand, internal debugging and individual developer whim -- and you can stave off crippling over-complexity for longer periods of time
It's clear that he means that we, as programmers, should be willing to throw away a shitload of code. I agree with this. I think there's a huge belief in re-use (I tend to it myself) among programmers for both practical and personal (pride...having spent weeks on certain code) reasons. But there are so many cases where the re-use of a small feature among others in bloated code can really complicate and bog down the overall code-base, or where the functionality of certain re-used code doesn't really fit, but so much investment has been made that it might as well be re-used.
Developers really do need to listen to the feedback provided by the marketplace and other forces. I'm not certain if the unified theory is so unified, but it's a valid perspective and blends in with other published sentiments on software development methodology.
'nuff rambling...