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."
While "Brook's law" might be a law, it's only useful in retrospect. Most software projects have no idea how far behind they really are. So basically, you can always add manpower, you're really only half way through anyways...
"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."
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.
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.
your simplification is somewhat faulty. If you have 3 people developing a large complex system, at some point it becomes obvious they'll need more than three in order to make the deadline, even if that deadline is years away, and especially if all three lack serious knowledge in a particular topic, such as databases or UI design. Think of what slashcode might be like if cmdrtaco were still the only guy working on it.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
From the article:
"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.
Someone else called this oversimplification. It all depends on the project.
_ __
The number of programmers needed on a project depends upon the number of software modules in said project. Each programmer working on their module and with the other programmers and project managers for the sake of integration and communication between modules talking to each other. I am not a project manager so I do not have the magic formula but there needs to be some serious research in the IT industry of how many programmers are needed per project for the number of independent sections or modules of software being created.
Then and only then will you have a situation of better utilized output over a large group of programming talent.
10 may me too few programmers for some huge program and too many for plenty of other projects.
_______________________________________________
ACK
If you've got the requirements well enough defined in terms of previous work that you can estimate accurately, then most likely all you've got to do is cut and paste the old code anyhow...
I've been trained in that stuff. It's wonderful in theory. In practice? All the metrics only work if you are doing the same stuff you've done before. If you are doing something new, then they don't work. Which is why few people actually use them.
Looks good on a resume, though.
Best Slashdot Co
Oh I don't know - when I worked in software testing it certainly seemed like the developers were just making random variations in the code base and we testers would weed out the broken ones and every once in a great while some random variation would be an actual improvement so we'd go with that, then start with the random variations on that code base.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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.
Back in the early 1980s I headed up a small team that developed 'industrial strength' applications.
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. (:-)
The basic issue is changing requirements. A contractor building high-rise apartments does not have to worry about the customer coming around when it's half built to look at it and say, "You know, I think I want a hospital instead." Programmers quite often have to deal with customers that are just about that confused -- they can't begin figuring out what they really want until they see what they asked for on the screen.
More than that, software vendors routinely write a program, release it, then add features so they can sell it again. It's as if the builder has finished the apartment building, and now they want a factory tacked onto the north side and a Wendy's onto the east. Next year, add a hospital wing to the west. Repeat once a year for 10 years and you get one hell of a mess, but how else would M$ keep a continuing revenue stream from the same OS and Office programs?
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.
.NET, but wouldn't it be nice if you could get up-to-date architecture diagram syncronization with code directly from a source versioning tool (ie. cvs, SourceSafe)?
I was talking about this with a friend the other day. Wouldn't it be nice if a senior software 'architect' could maintain a unit-level view AND current code at the same time? That way his busy programmers could refactor all they wanted, as long as they didn't overstep their unit bounds but at the same time improve the product. The architect could look at the project at different levels of abstraction (units, subunits) to make sure the programmers aren't getting off track.
Probably the hardest thing about using the iterative or refactoring methodology is knowing what your architecture looks like at any given time. You design a great, flexible architecture for the first iteration, but after several rewrites you may not know where you are in terms of the big picture. Surely a tool that spits out UML-like diagrams of the current code would be very useful to spot architecture flaws introduced during the refactoring process. Effective use of design patterns may also help. Is it impossible?
I've seen some work done by Rational in terms of code generation with
----- rL