“‘The creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line.” – Bollinger, T
Accurate estimation is one of the biggest challenges in software development. It’s a problem that has plagued the industry since its inception, and it’s one that elicits strong opinions from everyone involved in a project.
Every company has its own collection of horror stories about projects that have slipped catastrophically or seem to perpetually overrun their budgets and timelines. These delays can result in lost jobs, damaged careers, and, most importantly, destroyed relationships.
For some companies, this is such a common occurrence that the destruction caused by poor estimation has become the norm rather than the exception. In these environments, the trust between business and technology may be so eroded that any attempt at coming up with reasonable project estimates is regularly abandoned.
Instead, these companies are bombarded with unrealistic business demands that are labelled as “critical deliverables,” even though they are based on no quantifiable reality of effort. These “immovable” business targets are often arbitrarily tied to people’s KPIs, even before the feasibility of the work is explored. The recipients of these KPIs are typically people with no experience in software estimation and no understanding of the differences between an estimate, a target, and a goal.
At the heart of this problem lies the phenomenon of “discovered complexity.” For some reason, people view software development as a mechanical task similar to an assembly line in a factory. However, as research has shown (even mathematically), “the creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line.” In other words, software development is a creative process that requires a lot of thinking about unknown problems that constantly arise. These “accidentally discovered” problems can lead to more subtle and indirect problems that also need to be solved. This is called “accidentally discovered complexity.”
In simpler terms, at any given point in time, you don’t know what you don’t know yet, and there’s no way to predict how long it will take to figure it out when you do discover it. In this world, how can you accurately estimate how long something will take? At best, you can make a reasonable guess based on the information you have at that moment. But even this is problematic because the information you have about the problem domain changes and develops as the project progresses.
Given this, it seems virtually impossible to accurately estimate these creative tasks. Therefore, it’s essential to follow an iterative development methodology that includes a constant feedback loop for estimates. If you’re not continually re-estimating how long a piece of work will take based on all the new information you learn, you’re putting your project, and more importantly, your organizational goals and commitments, at risk. Do that often enough, and you’ll see the consequences unfold.