From the IEEE article Why Software Fails:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/05/the-long-dismal-history-of-software-project-failure.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/05/the-long-dismal-history-of-software-project-failure.html
Another timely example might be the disasterous Seasprite helicopter program for the Australian Navy. $1bn spent, helicopters grounded, software problems are being mentioned explicitly.
http://www.theaustralian.news.com.au/story/0,20867,19145841-28737,00.html
TheDailywtf.com is full of examples of why projects fail.
Ultimately, no one wants to take the blame, so analysis is as shallow as possible and no one learns and the companies frequently drive away their best workers while rehiring those they previously fired for complete and utter incompetence (except that those doing the hiring didn’t know, because those doing the firing are too fearful of libel lawsuits to actually record theier full motivations)
I was in just such a company. We fired a useless employee who drove the other employees nutz and provided zero work in return. Several months later, the employee was back and untouchable inspite of the fact that any work that WAS produced failed to meet ANY of the requirements provided.
I left a few months later and the employee was still there wasting time, money, while distracting and driving away those who could could actually perform their jobs.
The company tanked about a year or so later. Once the people who can do their job leave and those who stay learns you can get paid for nothing, your company’s life expectancy drops dramatically.
It’s great that companies are starting to admit that failures exist. One of the problems that I’ve seen in our industry is that if a product of any sort ships, it’s considered a success, whether it meets any requirements or not, and whether it makes any money or not. If it was late, over budget, and doesn’t do what it’s supposed to, it’s still called a success because it shipped. The people involved can put it on their resume and get off to their next job before anyone realizes it was actually a failure, and they get to do it all over again!
I think your two posts today are related – at least one of the reasons that software projects get out of hand to become collosal failures has to do with ego. It’s not as if people working on the project are clueless until the big rollout and then … oh, dang. Someone, somewhere either refuses to admit, or refuses to hear, that there’s something seriously wrong.*
That someone can also be the customer. We have a new central library here in Seattle, and a couple of years ago when it first opened, we got a behind-the-scenes tour. They had installed some hugely complex automated system for sorting returned books and putting them on appropriate carts – something like what the post office does. Yet it was apparent even in our short visit that the system was a disaster – we watched as they had to stop the line, as the various book-sorting machines made mistakes, and someone even showed us the hatch that someone climbed in every once in a while to retrieve books that had gotten stuck.
The folks running the thing were putting on a good face, but I wonder who the brave soul was who finally said “For the price of this system, we could have hired a hundred interns!”
This is also about where the hardware guys say “You see? Software isn’t engineering – this sort of stuff doesn’t happen with real engineers.” (“If Windows were a car, … yadda-yadda.”) Fortunately, we have the likes of Henry Petroski to remind us that more than one bridge has fallen down:
http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?z=yisbn=0679734163itm=1
- Of course, there’s also just simple nay-saying. When the Boeing 777 was being designed, I heard more than one old-timer say “That thing will never fly!” Because they’d used computers to design it, not pencils or whatever. Fortunately, Boeing persevered.
My comments are biased by 10 years working for government on contract, but my sense of it is that we have good methodologies available, the failure is usually one of the following:
-
magical thinking by managers (eg: neglect a major project requiring 6 months for several years and then promise it can be delivered in 2 weeks when a crisis has developed as a result of said neglect);
-
most managers and programmers do not believe good methodology works, or do not know it even exists, and therefore will not practice it (people who do are thought of as ‘dreamers’);
-
programmers do not understand how to organize their work in a failsafe and consistant manner (eg: their work is a random pile of paper and randomly scattered files across several computers; they do not execute their own code or complete one routine before moving to the next, saying source code control and OOP programming is too much bother to learn, etc);
-
political sabotage by a vested interest (eg: worker stands to lose frequent free overseas trips and massive overtime ‘maintaining’ the faulty system sabotages the replacement system by ensuring that critical specs are kept secret or changed every few weeks; bad programmers fail to deliver in a way that causes the good programmers to fail on their deliverables, sometimes maliciously).
Obviously, despite having numerous detailed examples on hand, this is about as much as one can say in public.
While failure studies abound (I have much of the same material on my site), what isn’t mentioned anywhere is the complexity of designing software. When I say designing software, I mean it is the source code that represents the design, nothing else matters.
Why is that? Why is designing software so complex? This is aside from requirements gathering and methodologies. While I can point at our industry as being unindustrialized compared to other industries (look at the electronics industry and ASIC design for example), it still does not explain some of the fundamental complexity issues while designing software.
I have made a case on my site that it really boils down to Brad Cox’s argument made several years ago where we don’t have a rich and vibrant market for reusing software components. Where components are supplied (from a catalog), reused on top of other components and assembled to produce a software solution. Until that day arrives, as Brad calls it, the Software Industrial Revolution, we are going to see more failure studies and more arguments to whether software design is computer science or software engineering.
while there’s no shortage of blame (or praise) to go around, I point the finger directly at management, particularly the middle echelons of management.
When I started working for a large videogame developer/publisher - no name provided here, but you know who they are! - I was amazed to see task estimates being bidded and bartered as though they were arbitrary figures. Time and time again I ran into situations where I or a coworker gave considered estimates only to see management go to someone who wasn’t even involved to get a competing (shorter) estimate. You can imagine which of those two numbers made it on to the project schedule.
Again and again we were told to “work smarter, not harder”, yet the only manifestation of this I ever saw was to place more managers on a team when what was needed was an additional artist or engineer.
Surely project management has to be about more than getting Excel or Project to output nicely formatted fictions?
Another interesting article to add to your collection : “Why Big Software Projects Fail: The 12 Key Questions”
http://www.stsc.hill.af.mil/crosstalk/2005/03/0503Humphrey.html
Here is the abstract:
“In spite of the improvements in software project management over the last several years, software projects still fail distressingly often, and the largest projects fail most often. This article explores the reasons for these failures and reviews the questions to consider in improving your organization’s performance with large-scale software projects. Not surprisingly, considering these same questions will help you improve almost any large or small project with substantial software content. The principal questions concern why large software projects are hard to manage, the kinds of management systems needed, and the actions required to implement such systems. In closing, the author cites the experiences of projects that have used the methods described and cites sources for further information on introducing the required practices.”
This article has some valid points, but I think they are being shrouded a bit.
First of all, we hear about spectacular software failures because that’s what makes news. How often do we hear “we just launched our new site, it’s making our client millions and it went off without a hitch!” ? You don’t. That’s not news worthy. What is news-worthy is when a company loses billions because of software failure.
Also, a large percentage of the time (in my experience), projects are late and overbudget because people who know nothing about software development are the ones who make said budget. If I tell you it will take me a week to write X, and you budget me 2 days, that’s not my fault.
Yes, as developers we should be held accountable for our code and we should strive to get better, which I think is the point of this article. However, to say that we’ve got a “long dismal history” is misleading at best.
I have to agree that part of the reason software projects fail is they fo not obey the laws of physics. when a brige or hardware component is designed the requirements are very specific. a bridge builder knows it needs to support trafic in both directions with known sizes and known weights. however when a software bridge is being designed(as to be used to do data conversion) the incoming data is many times more complex, sometimes the data is garbled but you never see half a car drive across a bridge.
Another interesting article to add to your collection : “Why Big Software Projects Fail: The 12 Key Questions”
Thank you for pointing this out. I’ve read that before, and it’s a great one.
My point is: hardware is less complex
I’m not sure it’s always less complex, but you’re playing by God’s rules when you develop hardware, which are a lot more stable:
By the way, you can’t compare software to hardware because of complexity. Why do you think hardware is as thin layer as possible everything else being software? Because it’s cheeper to make software doing same things than to make hardware I think. Why is it cheaper? Because you do a lot of design/test/redesign work in hardware but you can go away without it in software and that’s what makes it cheeper… You can always skip testing if You have no time left, making software copies costs virtually nothing anyway. Whereas in hardware you pay for the materials and such so to make one more copy costs you some money, to make a change in design costs you even more (e.g. new assembly line).
My point is: hardware is less complex, a lot more time is spent when designing hardware. Which results in hardware being more reliable. As simple as that I guess…
Your link to Failure Rate is hilarious: Coding Horror + Failure Rate = “Sorry, this key is disabled…”
When you think of the amount of castles and cathedrals that have sunk into motes…
I guess if you over exaggerate anything is possible.
Writing software is easy. Managing people is hard. Large software projects by definition involve the coordinated inputs of huge numbers of people. Those people must be managed so the sum of their inputs deliver the project to a useful end state. Therefore, large software projects are prone to various failure modes, and so long as they rely on people to steer them, always will be.
This principle is just as true of tin-bending as bit-smashing. It is no difficult feat to come up with similarly impressive lists of projects to build “real stuff” that came in grotesquely late and over budget, or were cancelled altogether. The US Dept. of Defense alone could fill entire books with lists of their failed hardware projects.
Another thing to note is that that cost of software failure is not just in the lost productivity and increased investment, sometimes there is a necessity to pursue litigation so that business can attempt to recoup losses. That means hiring expert witnesses like software failure experts and the like, and the issues that occur because of the original problems continue long after they source has been rectified.
@Asterion re: Source code is not design…
http://www.developerdotstar.com/mag/articles/reeves_design_main.html
what in your opinion is the most frequent cause of software failure.do you know which was the most silly software failure