Software Engineering Estimation
How soon we can meet again with meaningful information to choose further direction.
It is definitely:
NOT when can we finish, because we don't know what means finished means at the point.
NOT a measurement, it just placeholder to for use of coordination.
Problem isn't estimation. The problem is the question that we're asking for which we think estimation would be the answer.
Downside if team miss the date, no upside if they hit the date
Who wants to know, and what decisions rest on our answer; the crux of estimation.
If there are n people there is n+1 ideas of what estimate is (preconceptions)
Considered implicit commitment, but it is to know the target
97 things every programmer should know – 9 March 2010 distinguishing the nature of the question, what is estimate
estimation as a commitment is a probability distribution with long tail, not a symmetric give or take.
Clients doesn't want same thing as something else because we've already got that so we ask for something different and because it's different it's unknown either to all software developers or to us particularly as a team then the shape of that the variability on that is huge.
then we have the fractal measurement problem where the "closer we get to actually writing the actual software the bigger the software is" not just appears actually is and everything you implement spawns off tune more things that you want to implement that you didn't expect when you originally said when is it going to be done. So the the the thing we're measuring is continually growing.
particular case, it's the precision versus the accuracy. is days or months.
there were two people in the room who had completely different understandings. They were apparently having a conversation with the same words but they actually meant very different things. They wanted to do different things and they were suffering different uh anxieties around it.
so the answer to the question "can software estimation be be fixed" is actually yes. It's by figuring out what question is actually being asked, which is a relationship building exercise, which as geeks we're not terribly well suited for, but boohoo. figuring out what questions being asked, who wants to know, what is the the purpose, what decision are they going to make based on that, and then tailoring the activities that we do to meeting the actual need that's underneath the question, which from an engineering standpoint is simply impossible to answer with any degree of accuracy.
Roles involved and the consequences.
Can't do estimate due to Knowledge work's fractal quality.
Unwanted rituals and practices around.
3 categories, kinda too small to even worry about, bigger things certain level of knowledge, then the unknowns.
Those categories help reduce degree of wrongness.
reminded of another company and this one was actually stateside where we spend a meeting of six people arguing for an half an hour as to whether or not a developer should commit to about 3 hours of work. That's honestly 6 times half an hour we had already wasted the 3 hours that the developer was going to, I'm sitting there going why are we even doing this this is such a waste of time.
How do we have productive conversation about time? and time is elusive and fleeting, we all know this.
Last updated