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."
from www.dictionary.com
evolution
n.
A gradual process in which something changes into a different and usually more complex or better form. See Synonyms at development.
a. The process of developing.
b. Gradual development.
Seems like quite an appropriate term for 90% of the software projects I have ever worked on.
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...
- The Beagle tool is the work of my (recently graduated) M.Math student, Qiang Tu, done under my supervision. We reused the PBS landscape viewer as part of it (which is the work of my colleague, Prof Ric Holt; hence the confusion). More info about Beagle can be found in this paper.
- The study of Linux's growth and evolution is best documented in this paper, not the much shorter paper given in the salon.com article and elsewhere in these postings.
- The systems my group has looked at in some detail include the Linux kernel, GCC, and VIM. fetchmail was a quick one and the results were not terribly interesting.
- I am not an open source evangelist; I am a researcher
:-) I did not say that "large system development is best handled in an open-source manner". I said something more along the lines that open source development seems to work very well for certain classes of systems, especially large, service-based, infrastructure-ish systems like operating systems and compilers. I might have said that I thought open source development might be the best way to engineer these kinds of systems. That would be a personal opinion, tho.
Michael Godfrey PhD, Assistant ProfessorNortel Networks Jr Chair, Telecommunications Software Engineering
Univ of Waterloo, Dept of Computer Science
email: migod@uwaterloo.ca
URL: http://www.uwaterloo.ca/~migod