What’s wrong with software?


Surely nothing is wrong…

 In 1995, it reported that only 16.2% of software projects succeeded.  In large companies, the number was only 8%.  That is, these projects were on time and on budget.

The 2012 report is still fairly damning of the industry as a whole.  It cites 12% success rate for waterfall projects and 42% success rates for agile projects.  Firms like Headspring, with a 95% success rate, have embraced agile, of course, but there is still so much more to be desired by the track record of the industry.  In 2012, 9% of agile projects still out-right fail, and 49% are “challenged”. i.e. they unacceptably ran over budget and/or over schedule

Jeffery Palermo

OK, so maybe there is something wrong.“If cars were like software


  • Over Promising Estimations

“you simply don’t KNOW whether something is possible yet without research into it”

“Managers and sales guys can be really annoying; understandably, they have to tell THEIR employers what’s up in the development process and where we are. But if you give in and avoid disappointing them now, you will only disappoint them more later.”

  • Lack of good requirements
  • Budget constraints
  • Unreal expectations
  • over-ambitious goals
  • feature creep
  • (most likely), under-investment

So what can I do about it?

Build awareness so everyone can work together to solve this problem early.

“I assume you know how to put together a jigsaw puzzle, for nearly any 3 year old can put together the most basic ones.

So let me ask you a question. If I went out and bought 5 jigsaw puzzles, each with say 2,500 interlocking pieces, how long would it take you to put together anyone of them?

Can you tell me within 25% of the actual time how long it will take you? After all, you DO know how to put together a puzzle, right? And it you can do that, can you tell me what day you’ll have all 5 of them finished?

I want to know! And can you have your reply ready for me by 3pm today?”

Deal with misconceptions. We are not building cars we are designing them.

 What we need to do is get businesses to understand that when they undertake to have custom software built, what they are really asking for is not a construction project, but an R&D project.

Don’t ignore aspects of the business to give the illusion of agility.

Agile can improve things, but I have found that for most businesses, no matter how much you communicate that requirements need to be flexible, that you charge hourly for time spent, that adding things increases time and costs, at the end of the day they still expect to be billed exactly X dollars after X months for their exact scope, even if that scope exists entirely in their own minds.

Continuous Improvement

We have a lot to improve upon in our industry (education in patterns, solid principles, db techniques, soft skills, requirements gathering)

Make sure not to build in bad practice

I used to work for a company, which was making about 3x more money from supporting crappy projects they have built for 1x at the first place. That’s what happens when none of the stakeholders is anything close to technically literate.

Choose two

Cheap, Fast, Good-quality.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s