Devops, Agile, Method. & TestsConference50min
Software estimation is a delusion
Developers often give optimistic estimates, preferring exact numbers over accuracy, due to perceived competence pressures. Accurate estimates may not be the goal; rather, managing project risk and expectations is crucial. The best estimation models are team-specific. Shifting focus from precise estimates to risk management may better serve project needs.
Ines Panker
talkDetail.whenAndWhere
Friday, June 20, 13:45-14:35
Main Room
It has been known since the 70s that developers tend to give very optimistic estimations. We prefer to have exact numbers, even if that means they are wrong most of the time. But maybe it isn’t really accuracy people are looking for. Maybe it is all about risk aversion.
“It doesn’t have to be correct”, I was told, but I do have to give a number.
Searching for a good effort estimation method is too often compared to searching for a law of nature, for the natural relationship between software building and time, which is independent of the organization or the customer that the project is built for or by.
However, the best mathematical models for software estimations are those that are highly calibrated to the team they are measuring.
In research, developers admitted that they believe their managers will see them as less competent if they provide estimates with huge margins. But mathematically speaking providing a wider min-max interval means you will be right more often.
But maybe it isn’t really accuracy that businesses and people are looking for. Maybe estimates are needed for the sole purpose of risk aversion. People want to know what the risks of starting this project are.
Risk can be measured in other ways.
Maybe it is time we stop estimating tasks left and right and instead start managing the project’s risk and customer’s expectations.
“It doesn’t have to be correct”, I was told, but I do have to give a number.
Searching for a good effort estimation method is too often compared to searching for a law of nature, for the natural relationship between software building and time, which is independent of the organization or the customer that the project is built for or by.
However, the best mathematical models for software estimations are those that are highly calibrated to the team they are measuring.
In research, developers admitted that they believe their managers will see them as less competent if they provide estimates with huge margins. But mathematically speaking providing a wider min-max interval means you will be right more often.
But maybe it isn’t really accuracy that businesses and people are looking for. Maybe estimates are needed for the sole purpose of risk aversion. People want to know what the risks of starting this project are.
Risk can be measured in other ways.
Maybe it is time we stop estimating tasks left and right and instead start managing the project’s risk and customer’s expectations.
Ines Panker
I’ve been building software for almost 2 decades — writing code, shaping architecture, and leading teams. I started my journey in Java, surfed the PHP wave, and for the past decade, Python has been my weapon of choice.
I’m fascinated by elegant solutions to complex problems, finding simple, straightforward patterns in what at first glance appears to be unorganized chaos.
The best code systems are like well-designed cities: carefully planned, easy to navigate, and capable of growing without falling apart. The catch is to build foundations while creating solutions.
My other passion is to observe the human aspect of software.
The IT profession wants to give the impression that code is at the center of everything, technical details rule our world. But as soon as you look closer, you can find humans everywhere - we build software for people to use it, we build software in teams of people, we are being watched by the society of people while we built it.
My other passion is to observe the human aspect of software.
The IT profession wants to give the impression that code is at the center of everything, technical details rule our world. But as soon as you look closer, you can find humans everywhere - we build software for people to use it, we build software in teams of people, we are being watched by the society of people while we built it.
I’m fascinated by elegant solutions to complex problems, finding simple, straightforward patterns in what at first glance appears to be unorganized chaos.
The best code systems are like well-designed cities: carefully planned, easy to navigate, and capable of growing without falling apart. The catch is to build foundations while creating solutions.
My other passion is to observe the human aspect of software.
The IT profession wants to give the impression that code is at the center of everything, technical details rule our world. But as soon as you look closer, you can find humans everywhere - we build software for people to use it, we build software in teams of people, we are being watched by the society of people while we built it.
My other passion is to observe the human aspect of software.
The IT profession wants to give the impression that code is at the center of everything, technical details rule our world. But as soon as you look closer, you can find humans everywhere - we build software for people to use it, we build software in teams of people, we are being watched by the society of people while we built it.
comments.speakerNotEnabledComments