Slashdot Log In
A Unified Theory of Software Evolution
Posted by
CmdrTaco
on Mon Apr 08, 2002 08:39 AM
from the stuff-to-read dept.
from the stuff-to-read dept.
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 discussion has been archived.
No new comments can be posted.
A Unified Theory of Software Evolution
|
Log In/Create an Account
| Top
| 232 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Evolution is a MYTH!!! (Score:3, Funny)
Please check your crackpot theories and psuedo-science at the door.
Thank you.
Brooks' Law (Score:2, Interesting)
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).
Re:Brooks' Law (Score:4, Funny)
You realize you just suggested that very few software projects should have any programmers. How is the project going to get completed without anyone working on it?
Brook's law can't be used (Score:4, Insightful)
Re:Brook's law can't be used (Score:4, Funny)
True. I used to file status reports using Zeno's Work Estimation. On each report I just halfed the percentage of remaining work.
Can We Say... (Score:1)
"Adding manpower to a late software project makes (Score:2, Funny)
Seek and thou shalt find??? (Score:1, Funny)
Poor, poor man; he'll never find it I'm afraid!
mirror anyone? (Score:1)
Whow! He's still living? (Score:3, Interesting)
"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!
The key point is paragraph 9 (Score:5, Insightful)
Which means that commerical systems don't so much evolve as stub their growth paths out and switch direction or spawn new generations because embedded complexity has killed off the feasibility of maintaining it. In other words, all new releases are the cause of and ultimately an attempt to escape from, the chimera that is overly complex code. In commercial terms this should be astounding. We're paying to gronk up our own because we erroneously believe the NEXT version will be something radically new and elegant which of course it can't be.
New Version "x+1.y" is simply an ejection seat.
Blame it on C++ (Score:3, Insightful)
I'm not attempting to flamebait here, just submitting an observation. It seems to me that many of the complexity issues can be overcome by designing better languages. I've never stopped scratching my head over the perseverance of old languages like C++ and FORTRAN. Sure, they are extremely useful in the hands of experienced folks, but they need to die. They were good solutions to problems decades ago, but so much has been learned since then and the constraints of sparse computer resources and CPU speed have moved a lot.
He has an excellent point. (Score:1)
i want to see (Score:2)
Open source (Score:5, Interesting)
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?
Describes my job perfectly... (Score:2)
(And yes, I know about XP's "All code is shared.")
As for the maintenance, it's my normal experience, but the prohects I've been involved in may be atypical. (*cough*Canadian*cough*telecommunications*cough*g
We spend a *lot* of time reworking old code to (a) fix obscure bugs, many of which are slow leaks shown up by weeks serving live traffic (b) adapt the code to support new releases of underlying hardware product and (c) adding new features to satisfy users.
Sound premises. Sound reasoning. Wrong conclusion. (Score:3, Interesting)
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 [slashdot.org] 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%.
You're missing two premises (Score:5, Interesting)
No theory in Software Engineering? (Score:2, Insightful)
"In software engineering there is no theory,"
I don't buy that... at least not completely. I would say something more like, "In software engineering, theory is extremely underutilized."
I believe there are many instances of engineered software, but not necessarily high-profile stuff. A lot of DoD conscripted code may never the the civilian light of day, but there are procedures and documentation requirements that, flawed or not, enforce certain practices. Can we call that "theory"? Anyhow, defense suppliers can afford the extra development time, 'cause the government is forking over big bucks for the code to right.
For the mainstream (read desktop) apps, where all the money is, the time to market and feature pressures will continue to suppress even the best "unified theory" of software development.
Software Engineering (Score:2, Informative)
That's the point (Score:1)
99% of the consultants do this for a living. Get used to it.
What is Micro$oft thinking! (Score:1)
10,000 people working on Windows XP?
No wonder they have so many problems! The should have a smaller team of say, 20 or 25 people
(ugh)
We are only Human. (Score:2, Interesting)
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.
Computing Environment (Score:2)
- The functional capability of the OS too, since new hardware keeps coming out
and the Law of Declining Quality ("The quality of E-type systems will appear to be declining unless they are rigorously adapted, as required, to take into account changes in the operational environment").
Exactly what is happening to windows? And why Linux is so successful -> Open Source like fetchmail et al being more linear in their development, all users get a stab at getting the environment right.
But users who aren't prepared to do any work to make things better in their environment for their PC are always going to lose. But it's the same as those people who make their desks tidy and optimise them for work, and those that don't. The difference on your virtual desktop is that you can't easily hope someone else will tidy it for you...:)
it's all in the design (Score:2, Interesting)
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.
Re:it's all in the design (Score:4, Insightful)
Not only is this not true, it's impossible to do this in practice. If you do this, you'll find that you still blow a lot of time on design, development takes longer, because your design is unnecessarily abstract, and your design proves inadequate for something that you need to implement further down the road. Requirements change, and this has consequences for the design. The best one can hope for is that the basic architecture is robust enough that it doesn't require a complete upheaval.
What is necessary is a method for changing design gracefully. "Refactoring" is the best source I've seen that addresses this. Basically, you change methodically, and you test.
The answer is modularization (Score:2)
I think one of the reasons that Linux has been so successful is because Linus decided long ago to take a modular approach to designing his monolithic kernel.
-josh
No Interest in 'Doing It Right' (Score:3, Insightful)
Our firm licenced this software to major manufacturing firms with a Money Back Guarantee. As in, "If you are not satisfied, for any reason, we will either fix the problem or give you back your money. Your choice." We were never asked for a refund.
It was semi-open source. You could have the source any time you wanted, but asking for the source voided your warranty, since problems in your data might have been caused by your own temporary code changes.
Funny thing. I've had that on my resume for many years, but no prospective employer has ever asked how I did it.
No one has hired me specifically to help them produce similar quality code. Much of the time their reaction to my resume is, 'but you don't know c++' (or their other favorite). I know enough about c++ to know that I want to stay away from that second generation language for all but the most specialized situations.
I have also been told, on numerous occasions, that I'm not qualified to lead a particular project because I lack experience mannaging the large team that will be needed. I've never gained that experience because I've never needed a large team to accomplish anything.
As an MBA, as well as being an application designer & a coder, I know that large teams do have a place -- mostly where you have a blank cheque and are earning a percentage of the total billing. (:-)
Software craftsmanship (Score:4, Interesting)
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 [barnesandnoble.com] 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 [barnesandnoble.com] 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 [barnesandnoble.com]) 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 [agilemanifesto.org], including XP [extremeprogramming.org]. 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!
Best thing about this article... (Score:1)
More engineering = Less art? (Score:1)
Problem is in the structure of corporations. (Score:1, Interesting)
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.
Growing geometrically? (Score:4, Interesting)
From the article:
Is fetchmail [tuxedo.org] 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.]
oxymoron? (Score:1)
Somehow the last two words form a concept that at least from observation, doesn't really exist.
Then again I'm only 2 years out in the "commercial world"...what do I know?
Godfrey speaks (Score:1, Informative)
- 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 [uwaterloo.ca].
- The study of Linux's growth and evolution is best documented in this paper [uwaterloo.ca], 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
Height of evolution. (Score:2, Funny)
Where I work, it has been a commonly held belief that all software evolves until such time as it can send and receive email. If it doesn't do this, it isn't complete. :)
Jason PollockMittermeyer's Law Explains It All (Score:1)
F x (H-Q)
___________________ = man-hours
(P1+P2+P3, etc.)/nP
where F is number of Features,
H is Hobbling (range from 1 to 100),
Q is Quality Assurance (range from 0 to 100),
P1 is skill level of programmer on particular problem (skill level being from a range of
and nP is number of Programmers.
On (H-Q), use even if a negative number (excessive quality assurance can be as hobbling as normal bureaucracy), and treat 0 as 1.
This formula takes into account the complexity of the work the package is performing, the skill of the programmer(s) involved, the fog of bad user/organizational ineptitude, and the amount of QA work being done.
Software should not be described in terms of lines of code or database sizes, but rather by 'feature'. A feature could be thought of most easily as the list of salable points Microsoft and others use to sell their products. A feature can also be an internal function not recognizable by the user, but which aids development, error tracking, security or maintenance.
To use this formula in the context of the article, simply add a feature change to the feature number. Static applications will be a slight drain, but constantly changing applications will require man-hours, genius programmers and/or intensive QA work and a minimum of hobbling to reduce man-hours. Even with a fantasy level of positive factors, the complexity level will require features to be taken out, or a process to be started from scratch.
This formula also covers why Open Source has worked so well. OS brings together programmers to work on tasks they are well suited for on modules rather then one monster product, thus avoiding insane complexity levels. The peer review aspect quickly weeds out inept behavior, thus keeping the programmer skill level relatively high, whereas a corporation may not be able to recognize incompetence quickly.
Obviously plugging numbers into this formula is a highly subjective business, but then again so is Lehman's approach. Try this on for size- I would be very interested in hearing about real-world results.
"Software Engineering" as part of Computer Science (Score:1)
However, this field is not to be taken too seriously for its purpose is to overburden the programmer rather than making software better. We must understand that while "Programming Languages", "Compilers", "Verification", "Functional Programming", etc. *is* Computer Science, "Software Engineering" hardly is a science of any sort.
"Software Engineering" is in my understanding an icon of bigotry and inability to accomplish a good design, contrary to its popular advertisement as a means to achieve engineering goals. "Apply our methodology, and you can get 1000 monkeys to write your next OS!!"
If you have good scientists and programmers who know how to design software and their toolbox, you will be set. Don't waste your time with this bulls***.
Re:Wow a new methodology (Score:1)
Software Development is an art, it cannot be done by all people. Every succesful developer has his own way to evolve the software and give it powers, and no one can write a book or article on how to evolve the software to gurantee it will work better than its competitor.
The complexity price (Score:1)
That is one of the biggest problems: there is almost no factoring in of "complexity costs" in the decision process. Although it might take the same amount of time to add feature A and feature B, one may significantly complicate the system in the long wrong while the other may not.
As long as the complexity costs are never factored into decisions, it *will* grow messy over time.
Messy software is a management issue more than a technical one. If you (as an organization) spend complexity like a crack addict, you get what is coming to ya.