I recently received an interesting set of questions about software projects from a French science journalist. I thought my readers would like to see those questions and my answers, so here goes:
Q: Do large software projects fail at a rate significantly higher than other engineering projects in physical world (also quite complex!)
A: Well, as far as total failure, yes, I think s/w projects fail totally more than, say, building ships.
OTOH, the US Navy reported a few years ago that every ship built since World War II has been late and over budget, so that type of "failure" is 100%, even though we've been building ships for hundreds of years. The Wasa (or Vasa) Ship in Sweden is a good historical example of one reason for failure: the piling on of requirements until complexity is too great.
See http://en.wikipedia.org/wiki/Vasa_(ship)
Q: Do we know exactly why ? Is it a management problem or theoretical problem ?
All the failures I have studied have been management failures. In some cases, the theory might have been wrong, but management failed to notice the signs of impending failure, or noticed them but failed to act in time to prevent the project from becoming a death march.
Q: Have we reached now a critical size of dependable verifiable code, something like a "wall of complexity" ?
A: Such a wall definitely exists, though its thickness is somewhat fuzzy. Some well-managed projects can surpass the "wall" that stops poorly managed projects. But eventually, at any given state of the art, there will be a "wall," and as the project approaches its particular wall, progress becomes sluggish and expensive. When that happens, good managers recognize what's happening and take action--generally pulling back on some of the excess "requirements."
Q: Does it mean that "Internet of things", or other big things "real time" (like FAA air traffic) we would like to build with high reliability, are not really possible for the moment?
I first worked with the FAA in the late 1950s, trying to help them build the air traffic control system of their dreams. It wasn't possible then to implement their dreams, and it's still not possible. Why? One reason is that their dreams keep growing faster than our ability to implement them. They could build a better system, but when they try to build "the best system for all time," they collapse like the Wasa Ship.
Q: Is there a lack of a theory of building large-scale software (like rules governing civil engineering in physical world) ? Is it because computer science is still a relatively young science ?
A: There is a total lack of theory, but there are some empirical principles gained from experience. I've tried to catalog these principles in my Quality Software Management series (see below).
The trouble with computer science is that it's not a science, but generally a kind of mathematics without connection with the empirical world.
Rules governing civil engineering come largely from real-world experience, followed up by some scientific work in a few areas, like the properties of building materials. In computing, much of what we do know is simply not know to most developers, who are too busy trying to salvage poorly managed projects.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So, how do my answers compare with yours. Am I feeling too pessimistic, or optimistic?
Wednesday, September 22, 2010
Subscribe to:
Post Comments (Atom)
4 comments:
> All the failures I have studied have been management failures ... management failed to notice the signs ... or noticed them but failed to act.
My observation is that management often accept the death march as the normal way of things in software. Its the best they hope for. Striving for anything better is just a theoretical or academic idea to them.
They aim low and usually hit their target.
The first softwareproject failed, because nobody has done something like this before. But this failed project increased the expectations for all next projects, so as every following project does for their next.
If your project does not fail, then you do it wrong, then you did something, anybody has done before.
The trick: split problems into smaller ones. Hope for luck or count on your inability to fail every time. These solved problems will buy your lunch.
:)
I like your answers, but I'd also flip some of the questions. The questions are looking for causes of failure, why not look for causes of success, then generalize?
I like to study success stories, learning from the masters. Yes, they avoid certain things, but it's what they aim for and the processes that they use to reach their goals that I find most useful, most imitable.
Just sayin'.
It's obviously a gross simplification, but I often quote the level of healthy requirements churn as a factor on large projects. If 1% to 2% is healthy, over a 4 year project in theory what you end up delivering could be completely different to what you started with.
Post a Comment