3 ms·

Developers tend to have trouble recognizing and factoring in their own past failures. They mistakenly assume that the next project will be free of all the litt

by crusso 14y ago

Developers tend to have trouble recognizing and factoring in their own past failures. They mistakenly assume that the next project will be free of all the little gotchas and time sinks that plagued almost every one of their past projects. I've had developers working for me who had just finished a project that they said would take "a couple of weeks" that took a couple of months or so. They'd turn around at the next little project given to them of similar complexity and with a straight face said, "oh, a couple of weeks". Comedy ensued. I tend to make pretty good estimates in my own consulting for two reasons: I usually bill on a "not to exceed" basis and I keep really good records of how long things have taken me in the past. When I size up a project, I break it down into chunks comparable to chunks that I've bite-sized in the past. I look at those past chunks and I add up how long they ACTUALLY took to complete. I read the notes that I took during implementation to freshen my memory on the kinds of troubles that I encountered. I figure that same complexity plus similar work load means similar ACTUAL hours and resist my developer tendency to assume the best case implementation scenario. Also, by looking at past project estimates vs actual work, I've established an amount of inevitable overhead. I throw all these actual hours chunks into a spreadsheet that adds them up and includes my previously calculated overhead and normally I'm pretty happy with how on-target I end up being. [edited typos and readability]

mtdewcmu 14y ago
I think the estimate I'll give depends on who is asking. When my boss asks how long something will take, I lowball it, because if I gave myself plenty of time in the estimate, it might sound like I'm planning to work really slow. There's not much risk in underestimating, either. It's easier to ask for more time once you are half done with something. The fact that you're already half done puts you in a stronger position. I think I can estimate much better when I feel free to say any number at all, that I just don't know, or even that the project is not worth doing. I don't think managers should take estimates at face value, but consider the tone and the context and make their own estimate. Or, perhaps, not ask the employees to do their own estimating at all. It seems like the burden should be on the manager, and he/she may have to be creative. At my last company, they were crazy about making developers estimate every little thing, and it created an oppressive atmosphere that contributed to me leaving. For the reasons in the article, accurate estimating is almost the same as doing the work itself. And the estimate feels like a promise, one made without complete knowledge and in awkward circumstances. "I tend to make pretty good estimates in my own consulting for two reasons: I usually bill on a "not to exceed" basis and I keep really good records of how long things have taken me in the past." You have every incentive to judge accurately, because there is tremendous risk in making a commitment with too much uncertainty. You'd be better off not signing a contract than risking a wildly optimistic estimate, so naturally, you're only going to take projects where you can estimate pretty well.
xtracto 14y ago
This sounds a lot like Evidence Based Scheduling proposed by Joel Spolsky some time ago: http://www.joelonsoftware.com/items/2007/10/26.html http://www.joelonsoftware.com/items/2007/10/26.html The only additional thing he proposes is doing some montecarlo simulations to create a probability distribution of how long will the project take.

by crusso 14y ago

mtdewcmu 14y ago

I think the estimate I'll give depends on who is asking. When my boss asks how long something will take, I lowball it, because if I gave myself plenty of time in the estimate, it might sound like I'm planning to work really slow. There's not much risk in underestimating, either. It's easier to ask for more time once you are half done with something. The fact that you're already half done puts you in a stronger position. I think I can estimate much better when I feel free to say any number at all, that I just don't know, or even that the project is not worth doing. I don't think managers should take estimates at face value, but consider the tone and the context and make their own estimate. Or, perhaps, not ask the employees to do their own estimating at all. It seems like the burden should be on the manager, and he/she may have to be creative. At my last company, they were crazy about making developers estimate every little thing, and it created an oppressive atmosphere that contributed to me leaving. For the reasons in the article, accurate estimating is almost the same as doing the work itself. And the estimate feels like a promise, one made without complete knowledge and in awkward circumstances. "I tend to make pretty good estimates in my own consulting for two reasons: I usually bill on a "not to exceed" basis and I keep really good records of how long things have taken me in the past." You have every incentive to judge accurately, because there is tremendous risk in making a commitment with too much uncertainty. You'd be better off not signing a contract than risking a wildly optimistic estimate, so naturally, you're only going to take projects where you can estimate pretty well.

xtracto 14y ago

This sounds a lot like Evidence Based Scheduling proposed by Joel Spolsky some time ago: http://www.joelonsoftware.com/items/2007/10/26.html http://www.joelonsoftware.com/items/2007/10/26.html The only additional thing he proposes is doing some montecarlo simulations to create a probability distribution of how long will the project take.