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."
This can be simplified: "Adding manpower to a software project makes it later."
There's rarely that many programmers needed for a given task anyway. You need a project leader and lots of monkeys to test it... very few projects should have more than 10 programmers (if any).
//TheToon
"When I first wrote about this topic, nobody took a blind bit of notice."
No, sir, I did and many collegues who were also interested in good timely work. We lent your books to each other with the notion "that's something you should read".
Great to hear that you are still alife and enjoying to give programmers and their managers something to look at and something worth to read and think about.
Youngsters, better pay respect to this old software camel with the hole in the sole of his shoe (and probably also in his all-too British pullover), or I DDOS your toilet!
From the article:
Michael Godfrey, a University of Waterloo scientist, is equally hesitant but still finds the Lehman approach useful. In 2000, Godfrey and a fellow Waterloo researcher, Qiang Tu, released a study showing that several open-source software programs, including the Linux kernel and fetchmail, were growing at geometric rates, breaking the inverse squared barrier constraining most traditionally built programs. Although the discovery validated arguments within the software development community that large system development is best handled in an open-source manner, Godfrey says he is currently looking for ways to refine the quantitative approach to make it more meaningful.
It would have been interesting had they delved deeper into this finding. Yeah, I know, the true believers in open source all feel superior (we are, aren't we?), but exploring the reasons why it works would be interesting.
Is it the large-scale peer-review process? Is it that we occasionally rewrite parts (filesystems, VMM, etc)? Something else?
Although the performance audit showed that IBM researchers were churning out code at a steady rate, Lehman found the level of debugging activity per individual software module to be decreasing at an equal rate; in other words, programmers were spending less and less time fixing problems in the code. Unless IBM programmers had suddenly figured out a way to write error-free code -- an unlikely assumption -- Lehman made a dire prediction: 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.
Except that the "[dire] need of a successor operating system" isn't so dire at all: the world's richest man didn't get where he got by writing code that didn't need to be replaced by a successor operating system, did he? The whole premise is to produce something that works now, and when it stops working later, you sell a later version. Heck, just a couple of months ago, Billy announced that 92.3% of the calendar year would focus on new code, leaving the rest for the old.
What's smarter, coding the Microsoft way, or coding a server that's been up since before Windows NT was released, without a patch in 7 years, handling half a megabit of data both upstream and down, every second of every day forever. Where's the revenue?
~r~
Note: the 92.3% figure might only be for the year 2002, with later years being still closer to 100%.
I was interested in the fact that some researchers have only recently come to the conclusion that software is written by people.
It is questionable how useful purely statistical methods are in these situation.
One thing I would be interested in knowing is how staff turnover effects development. For matainable software to be possible a consistent approach must be maintained on adding new functionality, this usually requires deep understanding of alrge code base, and if your programmers keep changing, the newbies may not follow the rules.
Choose your allies carefully, it is highly unlikely you will be held accountable for the actions of your enemies
I worked on a system running OS/360, up to Release 23 or so, when IBM 'retired' it.
We installed new Releases about once every 6 months. IBM also had 'patches' available for about 19,000 known bugs.
These patches were not incorporated into the latest release because each of them, if installed, broke some other aspect of the OS.
We, and every other site, only installed those patches needed to work around problems that the particular site encountered. And you always hoped that today's patch would not break something else that your users needed.
it just goes to show that 99% of the work in creating software is in the design.
you have to try to map out not only what you will need but what you might need in the future.
yes, it's a near impossible task but it's the only way to avoid automatically commiting yourself to an endless cycle of patches and hacks.
the good part is, if you can plan the project well enough then the actual coding becomes nearly trivial.
the problem arises when the boss says 'i don't care about scalability or flexibility, i just want code now' and i have to try to explaining that i'm trying to save his ass 8 months down the line when clients (and not to mention, the boss himself) bombard us with feature requests, etc.
Now, this wouldn't be bad, if the skilled programmer had, at his disposal, the means to tweak the garbage collector implementation to suit a particular application -- presuming that there is one and and only one universally "best" garbage collector is arrogant and short-sighted. The trouble is, even though it may be possible to replace the Java garbage collector, one can't do it with a Java implementation: the language is not closed with regard to it's run-time requirements -- garbage collectors need to manage raw memory via, ta da, pointers! This lack of closure, preventing a language's run-time library from being expressed in the language itself, is most inelegant.
Of course, the C and C++ affecionados will point to this closure as the very beauty of their preferred language. Let's call such languages "complete". Alas, the linguistic power necessary to make a language complete has now been put into the hands of the neophyte programmer (was that delete or delete[], and when does it matter?).
It doesn't take much inspiration to see that subsets of a complete language, while not complete themselves, may still be powerful enough to write useful programs. With abstractions, disciplined programers try to fake this: the C++ "smart pointer" exercise is classic. Unfortunately, for all the effort put into smart-pointers and per-class address-of operator definitions, you can still get a real pointer to an object which does not implement such a monadic operator. What you really want is the compiler to say, "Bad programmer: using a real pointer!" either as a warning or as a fatal error (well, maybe not so harshly, but you get the idea).
You could've hired me.
To a Lisp hacker, XML is S-expressions in drag.
A quick warning... I consider myself a relative newborn in the world of software development. I present these opinions under the consideration that my opinions can change at any moment. =]
A lot of the dire predictions of software atrophy and such are a result of applying the wrong methodology to a project. Yes there are uses for Software engineering, but I think this approach is overkill for even large scale projects. Check out Software Craftsmanship: The New Imperative for a different perspective. A perspective I think is in need of serious consideration. The gist is returning to the days of master craftsman and apprenticeships. This focuses a bit more on the learning aspect than actual development methodologies, but you can always go to The Pragmatic Programmer to fill in that gap.
"As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress."
This is where "refactoring" (see Fowler's Refactoring) really shines. I find it difficult to believe that refining the software base is not progress. An initial revision where the code functions by its contract (if your into designing by contract), then you refactor the body of the function/method for speed / elegance. Then you can run your unit tests on the function / method to test that the refactoring session did not break any of the design contracts (whew).
I think they may be trying to restate the broken window theory (see Pragmatic Programmer), were a broken window (or bug) in a building (or system) leads to delapidation elsewhere in the building (or system).
And then there are the agile methods, including XP. I think these answer a lot of the limitations and issues with Software Engineering practices. Interacting with clients (having a client there during each iteration) gives you the benefit of almost real-time feedback so that you can update your user stories on the fly, etc.
Without rambling on any farther, my point is not too spend too much time looking for a specific unified theory. Read up about all the ideas, methods, and theories. Take the best parts from each, then crank the knob all the way up (if I may borrow that from XP =] ). Don't let anyone tell you there is a science to software development that is easy to reproduce, and that you are just a link in the overall chain. You practice and perform a craft. Enjoy it!
Ada was supposed to be that silver bullet (although Pascal diehards have their issues with Ada), but the darned trouble is that Ada is not showing a large-enough (maybe 5 percent) quantifiable improvement over C++.
Java is another of these silver bullets, and the claim is that people churn out a lot more stuff, but I have not heard about reliability.
Maybe it is how you structure a design and the code implementation is more important than the hand holding (or hand slapping) of a particular language.
We had a case were a system no longer proved ameniable to feature addition or continual improvement to match the changing operational and customer requirements. In the end the benefits of refactoring the codebase to match the changing production requirements were more costly than to rewrite the system using more modern libraries, methodologies and frameworks. It got rewritten and the old system phased out.
It wasnt a case of "fixing" inherently broken software, it worked perfectly well, just the operational flow it supported changed due to new customers and more efficient management procedures.
Incidentally we have found with each major rewrite of that system ( there has been two ) there has been an immediate growth spurt in customers. I am not sure if it is because it looks like something new, or that the software better matches the operational requirements or because of increasing feature addition. Either way the last two rewrites have been paid for almost immediately by the addition customers the new software has brought in.
mocom--
In the software industry, it is not uncommon for the developers to be far more intelligent and knowledgable than their managers. This creates more than resentment, there is a fundamental conflict. The manager is setting the deadlines, and yet the developer is the one who knows that all deadlines are bullshit.
This is the reason most software sucks.
From the article:
Is fetchmail complex enough that it needs to be growing geometrically? I mean yeah, fetchmail does a lot, and I do know what "geometric" means. Still, I doubt the world of email is changing fast enough that you'd want to choose that as your example of out-of-control software maintenance.
[Insert obligatory ESR goading.]