The Gut Instinct Equation
Filed Under Human FactorsEvery developer has heard permutations of Hofstadter’s Law such as “90% complete, 90% of the time”, but can subjective gut progress estimations be roughly quantified? Leon at secretGeek had an interesting thought on measuring perceived progress via circles. His charted equation is as follows:
What is freaky is just how closely it matches reality. For example, you believe you are:
- 50% complete – reality is 15%
- 80% complete – reality is 40%
- 90% complete – reality is 60%
So this brings me to the question, why does this match reality? The two most obvious reasons are underestimation and feature creep.
Underestimation can come in many different flavors, but I am guessing (solely from personal experience) that developer optimism is the most common reason for this gut instinct equation. Since, my team solves the hard problems first it is not uncommon to hear “If we got that done, and the rest is cake. We are 90% done.” Well…no. You are not done. There is still unit testing, documentation, installation scripts, QA testing, etc etc.
On the other hand, feature creep seems to have a unique relationship with this equation. When it comes to unspent budgets, Parkinson’s law never fails and gold platting occurs from both the developer and client side.
Work expands to fill the available time – Parkinson’s Law
If 40% of the time is chewed up in the last 10% of progress, what would be the return if we just scrapped the last 10%?
Knowing that progress is never linear is the first step in understanding why projects are never under budget. The disciplined developer can avoid gold platting, but responsible software development includes communicating to the stakeholders about feature creep. Learn to walk away at the correct moment and you just might save time, money, and aspirin.
9 Responses to “The Gut Instinct Equation”
thanks for writing this up. You made it make a lot more sense than i did!
cheers
lb
Thanks Leon! I found it a unique way of looking at things, so keep up the out-of-box thinking =)
I’m constantly amazed at how utterly horrible developers are at estimating time. Developers think in terms of features left instead of actual time remaining. In the past it was a constant struggle to get devs to turn features remaining into somewhat accurate quantifiable hours left to deployment. This graph really supports this sad fact LOL
Hi Leon,
How do you think this is affected by an agile approach? Especially in the case where the customer is highly involved with setting the priorities on (back-log) requirements. In this case the feature creep will be much more visible to that customer, but also the end functionality will be more in line with the customer’s expectations, rather than containing a whole lot of wizz-bang with little business benefit.
The other side of the coin is of course making sure that the requirements that do make it into coding is documented sufficiently in order for the test team to effectively test the system. This is especially important when doing regression testing after refactoring.
@Bruce –
I don’t know if Leon is subscribed to the comments, so let me take a crack at this (if you are Leon, feel free to jump in).
I agree that in a SCRUM/Agile project where sprints are explicitly mapped out, this chart melts away as you will not need to speculate on progress – true progress will be seen in burn down/up charts.
However, we are currently viewing this at the project level which does not make sense when SCRUM is applied. If we get more granular, we could apply this to the time or estimation of a single feature.
Long story short, people stink at estimating anything and I found this a clever way of recalibrating perceived progress.
@Bruce + Max
Yep I’m subscribed…. but i don’t have much of an answer.
I like Max’s response. So just pretend I said that, OK 😉
Hi Max,
Nice to meet you. I totally agree that people stink at estimating anything. I really like the recalibration chart.
The other part of estimating is before you have started the project and have only high-level customer requirements. Then the customer goes to you: So how long will it take and how much will it cost me?!?
Even worse, they demand a fixed price/fixed outcome proposal, but are not willing to get down into the detail of the requirements until they have signed off on the project.
(Pretending Leon wrote it)
@Bruce –
Leon’s chart recently gave me an idea of how to handle that situation. Stay tuned and I will write a post on that soon.
You really have it in for charts :D.
It’s just an observation, the truth is that as long as you offer a model for the readers that they can understand it’s not bad.
Keep up the postings and charting ;). Thank so much, it’s growing into a nice place for Agile resource references.