Dispatches from Andyland "Your reality, sir, is lies and balderdash and I'm delighted to say that I have no grasp of it whatsoever!" — The Adventures of Baron Munchausen

November 5, 2006

Lies, damn lies, and statistics

Filed under: Uncategorized — Andrew @ 12:19 am

In Why Software Sucks, Chris Stewart comes up with a statistic 80% of projects fail. I’m guessing is is misquoting a Standish Group report, whose figure can is more accurately quoted in Best Practices for software development projects. It says “over 80% of projects are unsuccessful either because they are over budget, late, missing function, or a combination.” I don’t have the $99 for the most current version of their report, but their 1994 version is of The CHAOS Report online on their website.

From what I’ve read in places like IT Myths (#5 Most IT Projects Fail) the Standish Group’s sole purpose is to study and report on the success and failure rate of corporate IT. Their criteria of success is pretty high. From what I can see higher than any sort of project initiative I’ve seen for any company, whether the project involves IT or not. I don’t think I’ve gotten a better success rate from home improvement contractors, electricians, or plumbers working on my house. I’m not saying Standish’s criteria is wrong or should be more lax. People making business decisions should know this sort of information. (If nothing else, don’t get so wrapped up in the dream of what things will be like at the projects success to ignore the fact that it might fail)
It might be that he lead off with an incorrect figure to prove his point colored my viewing of the rest of his essay. Or maybe he is as naive as I think he is.

Yes, agile approaches to development are great when you can engage the “customer” fully. On the other hand, there are drawbacks. What if there isn’t one person who can’t speak for all the stakeholders. (Either the boss who doesn’t know enough about what her workers do to give the right answer, or she nominates one employee to speak to what they need, and the one employees view winds up being different the rest.) What about the overhead of small iterations. Iterations have to have some sort of design and QA phases. In many environments, developers would be better of getting more feedback sooner, and being able to keep closer to what is wanted or needed. (similar to what the the rules in the book The Pragmatic Programmer desribe as “tracer bullets”) On the other hand, if an organization is really set up to get it done in one shot, then they could probably save time and money dispensing with the overhead of intermediate iterations.
Stewart complains about needless abstractions that make a project harder to understand by people coming into a project and not of immediate benefit to the customer. The counterpoint to that are the needful abstractions that keep a software project flexible enough to allow these customer driven changes to be implemented quickly and easily. No the customer doesn’t care if what you’ve built has all of the database related functions in a data access abstraction layer or SQL scattered throughout the project. He will care you can’t make schema changes quick enough to accomodate the changes in his business or product line.

Simple software that is quick and easy to develop and modify, so software should be as simple as it can be based on what it needs to do. Most software isn’t complex based on the whims of the developer. Most software is complex because the problem it is trying to solve is complex.

Decisions of agile development or detailed analysis, abstract and flexible design or simple and concrete, able to be delivered quickly or able to be maintained for 5+ years are all engineering tradeoffs. Which tradeoffs are chosen depend on the project and customer at hand. Someone who says that there is only one solution probably is going to fail badly when the they try to implement their same cookie cutter solution to a different problem and environment.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress