From an older Slashdot comment on the subject: I multiply all time estimates by pi, to account for running around in circles.
Why Can't Developers Estimate Time?
81–90 of 134 posts
Re: Why Can't Developers Estimate Time?
#82I am asked to give estimates all the time, sometimes based on something like "A guy down the hall says it crashed, how long will it take you to fix." or "Bob wants a portal site". So I've come up with a method that works for me. Add together hours based on what things I will need to fiddle with to get it to work.
•Involves strange business practice I will have to figure out or gleen from area experts +5h
•I didn't write the code +5h
•Involves something like wcf or msmq +3h
•It is a "it is too slow" bug +3h
•Involves stored procedures +2h
•Involves 3rd party UI component +10h and so on, and so on.
Re: Why Can't Developers Estimate Time?
#83Earlier quoted context omitted.
Well, yes, but too often "soft" requirements get lost, like performance or the ability to be supported by anyone who wasn't the author. I'm not IN support, but I've been there and man I feel for those guys. Getting crap dumped on them that has no documentation, architectural designs that were pulled from someones backside in the heat of the moment of getting it done quickly, inconsistent standards being applied, whee…
Prototype is really a dirty word in programming, but there's no reason you can't produce a small, well written app which does some of what's needed and build from there. As opposed to a crappily written ball of mud which does most of what's needed, but poorly.
> but there's no reason you can't produce a small, well written app which does some of what's needed and build from there.
Depends on where you work, I guess. Part of my personal hell right now is our architecture (which was written "elsewhere" and is given to us from on high) prevents such luxuries. It's an all-in affair, and deviation is met with retribution. Unit testing is nigh impossible with it, so I try to unit test the best I can of MY stuff that gloms onto its bulbous, massive exterior.
I agree with your point; don't get me wrong; but sometimes there are external forces at play that make the "right way to develop" hard to impossible.
Re: Why Can't Developers Estimate Time?
#84I am great at estimating time. I can tell you within 15 seconds plus-or-minus how long it will take to copy files from one server to another.
That's where any valid comparisons to construction or manufacturing end.
Re: Why Can't Developers Estimate Time?
#85Earlier quoted context omitted.
You know there is a saying in the creative industry when project managers come knocking on your door. "You want it know, or when it's done?" My personal experience is that most deadlines are primarily perceptual.
I think an under appreciated gift Apple has given the world is the patience to provide something when it's done , vs. possible.
Ohh Apple is on a completely different planet.
They follow the principle of "The best way to predict the future is to invent it"
so yes you are totally right about that.
Re: Why Can't Developers Estimate Time?
#86Earlier quoted context omitted.
But from your manager's perspective, you probably do know. You know if it will take more than or less than a year. You know if it will take more than or less than a month. You have some idea of what needs to be done. You have some idea of what parts of it you don't know, etc. One of the most important things I've learned about estimating is first asking how accurate an estimate is needed. Often the person just wants…
Depending on the task, it might not actually even be possible. Or, it's doable but not without rewriting major libraries or buying hundreds of servers.
And all those things you've just said are valuable pieces of information to the person asking!!!
Re: Why Can't Developers Estimate Time?
#87I think the main thrust of the article is factually correct (you can't estimate the creation of something new), but I don't think that's a very satisfying answer because you can't do anything about it.
In my opinion, the single biggest problem with developers doing estimates is that they think they're being asked for a commitment, or they are being asked for a commitment but the asker is calling it an estimate. This creates a large number of problems in expectations and communication, and it causes the whole project to break down.
There are some things that can be done on a project to help improve communication about estimates, commitments and targets:
- Ensure that estimates, commitments, and goals are understood to be three separate things.
- Ensure that everyone knows the benefits and uses of estimates, commitments and goals, as well as the non-uses. This is doubly true for estimates: many people treat them as commitments, but in reality they are supposed to be indicators that can be used to help control a project and make it successful.
- Encourage people to put effort into their estimates. Developers often don't like working on estimates because every minute they spend working on them (or on other stuff like timesheets and status reports) is a minute they could have spent thinking, designing and coding. Ensure that everyone knows that spending time on estimates and other activities is truly valuable to the project and the group, and helps ensure success.
- Do everything possible to remove stress and pressure around estimates. Reinforce the idea that estimates are used to help steer the project to success, not to hold peoples' feet over the fire (if a PM is trying to shrink estimates or pointing to estimates after a project has started and saying "tasks x, y and z are late," they're doing it wrong).
- Make it known that estimates are supposed to have some uncertainty. Don't accept or expect single-point estimates, and make sure the people delivering the estimates aren't pressured to do so.
Re: Why Can't Developers Estimate Time?
#88Good post Ash (good to see the discussion being consolidated) IMHO - it's usually due to the lack of "up front planning" by Managers / Analysts. If you compare building software to more general "building endeavors" (for example building the Olympic stadium) then, IMHO, developers are really the "construction workers" (the people actually doing the work). However no intelligent Olympic committee would countenance star…
No! That was the orthodoxy for 40 years and it got us nowhere, because the construction metaphor is fundamentally wrong.
Re: Why Can't Developers Estimate Time?
#89Which part of the meaning of the work "estimate" are we missing:
"an approximate judgment or calculation, as of the value, amount, time, size, or weight of something."
??
Re: Why Can't Developers Estimate Time?
#90Developer estimation improves when the developer is estimating the time for a task that is repeatable and they have experience or data on how much time the task took in the past. Substitute any title for "developer" in the previous statement and it remains true: civil engineer, drywall installer, plumber, etc.
The challenge is that relatively few developer tasks are highly repeatable, and very few developers are disciplined about collecting data on how long similar tasks required in the past. Also high performing developers get bored easily and frequently want to chase the new shiny tool/framework, where they have no past experience or data to rely on for estimating.
A first question in asking a developer about their estimate is "have you done this type of task before with the same technology you are planning to use". If no, disregard any estimates.
You can get good estimates for high volume of task teams, like maintenance or break/fix teams where the technology remains relatively static from one work iteration to the next, and the work items can be bucketed into meaningful and consistent sizes (T shirt sizing or what have you). Those are typically where you have your junior (or offshore) developers staffed as they pay their dues, and they can benefit greatly from having discipline around collecting data on their actual experience and using that data to reduce variance in estimates vs actuals in the future. This is also a great space for a new dev lead or manager to cut their teeth on managing the consistent collection and application of this data to reduce variance to plan.
For the really fun work though, where your high performing developers want to be operating so they can thrive and experience self-actualization (see Maslow), forget about the estimating angst and just timebox them or go agile -- build something, release it, refactor it, repeat. Don't waste your time creating the illusion of certainty about the future when you have nothing but optimistic gut feel as input to the estimating machine.