A case against — “Spare Parts Estimation Technique” in Software Development”
- Daksh Gupta
- Jan 17
- 3 min read
I
In the past five decades of mainstream software development, significant progress has been made in nearly every area except for one known as software Estimations.
This is the single factor that affects all software development activities, yet lacks a scientific method for precise determination, but is still regarded as sacrosanct for planning and execution.
Software Estimations — The General Practice
The universal technique is to break the software into smaller independent items and estimate them individually.
The final estimation will be the sum of all — Some adjustments here and there are possible, like parallel developments et.al.
If you’re a software developer, you are aware of this irrespective of the organization you work for.
Why we do estimate in this way?
The fundamental idea of this arrangement is that the likelihood of errors in estimating smaller items is lower, significantly decreasing the overall probability of mistakes.
But is it really the case?
The answer is obviously NO
Now, before going ahead and talking more about the software estimations, let’s talk about a common activity we all do or will probably do in the future.
Let’s talk about buying a Car
Let’s assume that you want to buy a car, and it will cost you, let’s say X
Now what if, instead of buying the car, you buy all available spare parts which are used for making the car.
How much it will cost?
In general, it will cost you more, it could be anything between 2X to even 10X more than the price of the car. This is true, not only for the car, but for countless other things.
Why?
When you buy spare parts, you get them wrapped separately, you pay taxes on it individually, they may be shipped via different (multiple) means, and may have many other additional costs.
So buying spare parts will always be costly (inflated), unless you’re dealing with manufacturing of the car itself.
Okay, I understood, but how this is related to Software Estimations?
In today's software development, the focus is on estimating the individual components rather than the entire software.
If you divide your software development into smaller parts and estimate each one separately, it significantly raises the time and cost of the software development, leading to the inflation of Software Estimations.
Wait, WHAT? We barely manage to finish things on time and you’re saying that we’re inflating the estimates.
Yes, I'm
Now, if we’re not able to complete things within the said time, the blame goes to
Spare Parts Estimation &
Parkinson’s Law
I’m NOT going to talk about Parkinson's Law because it’s a well known thing, let me talk straight about the Spare Parts Estimation Technique
The pitfalls of Spare Parts Estimation Technique
The biggest problem with Spare Parts Estimation Technique is that it takes your focus and efforts away from the Big Picture
Let’s take a cue from Google Maps
Whenever we use google maps, it shows the time it will take to reach the destination? As an example, the google maps below show the time you’ll take to reach JFK from Manhattan
Disclaimer: The time shown in the maps is indicative and may not be accurate. Don’t consider this time for planning your travel
Now, What if, instead of showing time to reach the destination, google maps gives you a timeline for each and every mile and put a constraint on completing the same
Believe me, it will lead to serious chaos, has the ability to cause accidents, and will pressurise the drivers and occupants of the vehicle for the complete journey.
Some miles may be covered fast, some will be slow, but its the overall time will remain the same whether we’re stressed about the next mile or not
The Spare Parts Estimation Technique is all about being worried about the next mile all the time instead of thinking about the destination.
Why?
Because Software Development is NOT a bricklaying activity. It’s dynamic and nothing is completed till everything is complete. It needs a broader mindset to keep the overall software in mind.
Alright, so what should we do instead?
Don’t estimate the miles, estimate your destination
And let the teams work on the common timeline to complete the work. Let’s them work backwards based on the available timeline instead of letting everyone run in all directions and coming up with unrealistic but still unachievable estimates.
Hope this was helpful to all of you..
Thanks for Reading .
Daksh
P.S: Reach out to me if you think I can help you to plan and do your software development in a better way.
Comments