Software Estimation with a Grain of Salt

Unlike many other goods and services, the process of estimating software cost is uniquely difficult. In this post, I’ll address some of the factors that contribute to this difficulty and explain how Agile methodologies seek to counter-act it. * The Software Industry is Still Young Unlike a lot of other goods and services we purchase daily, the software industry has only been in existence for about thirty years. This means that the tools and processes used to build software are still evolving, at a quick rate.

Unlike many other goods and services, the process of estimating software cost is uniquely difficult. In this post, I’ll address some of the factors that contribute to this difficulty and explain how Agile methodologies seek to counter-act it.

  • The Software Industry is Still Young

Unlike a lot of other goods and services we purchase daily, the software industry has only been in existence for about thirty years. This means that the tools and processes used to build software are still evolving, at a quick rate. The best practices and techniques currently employed today (such as object-oriented development and Agile processes) are relatively new and being revised even while they’re being adopted!

The fundamentals of software are changing, and the industry is still developing the key principles that will lead us into a more stable future – or not. Maybe software will evolve forever as it takes new shapes to increase efficiency and quality of life. Either way, this makes developing estimates more difficult as the terrain continues to shift and evolve.

  • Software is Virtual

Unlike the majority of products that are bought and sold, software, being intangible – or ‘virtual’ – presents some

issues. Since software lacks a physical dimension (i.e., it can’t be touched or really seen in any meaningful fashion), it makes progress difficult to measure and likewise makes the impact of changes difficult to communicate.

This intangibility also tends to encourage requirements changes up to and including the final days of the project. Too often, this results in a project “death spiral” – new requirements result in new software code, which having been rushed into development introduce new defects, which result in more testing, which results in more customer oversight, which results in new requirements… and so on. If the project is practicing rigorous change control, it will likely grind to a halt under paperwork and administration.

  • Software is Usually Unique

When it comes to building custom software, vendors very rarely have the ability to base their estimates on previous projects that are truly relevant to the one being developed. This is because each custom software project has a unique set of requirements and a unique set of accompanying risks to go with it.

Navigating these waters is not unlike whitewater rafting – while

you’ve rafted this section of the river before – this time, the weather, the chop of the waves, the strength of the current are all different. This increases the risk that things could go off track and makes predictable estimation difficult.

  • Where Do We Go From Here?

Agile software methodologies counter all this uncertainty by embracing it. Instead of creating scope and requirements control processes, Agile emphasizes prioritizing requirements and development of the most critical features first to counter-act budget risk. Agile also encourages “early-and-often” customer testing of software to validate early project assumptions. Agile also emphasizes modular development techniques that make changes easier to execute as they inevitably occur.

So, is your software vendor Agile? Be sure to understand the level of budget risk in your projects and ask how your vendor plans to accommodate the inevitable uncertainty of a software project!

Rich Tolocka

Rich Tolocka