Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Can't Developers Estimate Time?

blog.patchspace.co.uk

Post reply on HN
Print view View original

61–70 of 134 posts

Re: Why Can't Developers Estimate Time?

#61

Post by HeyLaughingBoy »

larsberg wrote: post #43

I'd say that people can't estimate time because it's an acquired skill and most people don't try to acquire it. When I managed a team, I had people put their initial estimates in the tracking tool, and when closing out the item they'd also fill in how long it actually took. Then, some of the report generation tools would let them see how accurate they were. There were no review metrics associated with being accurate,…

when closing out the item they'd also fill in how long it actually took

Excellent idea. We do this and it really works well to see how far off your estimates were. Feedback is essential to controlling any process!

Re: Why Can't Developers Estimate Time?

#62

Post by silvestrov »

diegob wrote: post #54
bartonfink wrote: post #45

Earlier quoted context omitted.

A serious attempt to provide a precise, correct answer to the ? "What do I really want done?"

So things like prototyping, UML, use cases, and Agile were not a "serious attempt" to answer that? I think it's also unwise to tell your manager "it'll be done when it's done."

UML is a description of the engine. It doesn't answer: "do we need our own transportation device instead of taking a taxi?"

Re: Why Can't Developers Estimate Time?

#63

Post by HeyLaughingBoy »

RyanMcGreal wrote: post #31

This: > It's not just developers that are bad with estimates either. Everyone at some point is just winging it because it's something they've never done before and won't be able to successfully make a judgement until they have. When my manager asks, "How long will this take," about half the time my honest answer is, "I don't know."

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 to know "can I have it tomorrow, or will it take 3 months?"

Re: Why Can't Developers Estimate Time?

#64

Post by VMG »

wladimir wrote: post #44
VMG wrote: post #41

Earlier quoted context omitted.

The same thing has to be done in engineering. Just because creativity is involved doesn't make programming an art. Art can break rules and you can sell weird color splotches for millions, but the output of your /dev/random will always be worthless.

You could equally say "Just because math is involved doesn't make it engineering". But I suppose it's something in between art and engineering. With regard to "sell weird color splotches for millions" - Isn't that the same with code? You can sell a simple game or app to millions of people and become rich. The amount of money you earn doesn't have any connection to complexity.

You are right, there is a sub-gendre of entertainment software that does have similarity to art. But even there you'll never buy a product because it crashes, while a work of Art can be valuable because it is ugly

Re: Why Can't Developers Estimate Time?

#66

Post by anthonyb »

diegob wrote: post #54
bartonfink wrote: post #45

Earlier quoted context omitted.

A serious attempt to provide a precise, correct answer to the ? "What do I really want done?"

So things like prototyping, UML, use cases, and Agile were not a "serious attempt" to answer that? I think it's also unwise to tell your manager "it'll be done when it's done."

Largely those are things done by developers, not by the business. Perhaps in cases where the business is on board with them (eg. Agile and rapid iterations), but mostly they'd rather handwave and hope for the best.

Re: Why Can't Developers Estimate Time?

#67

Post by anthonyb »

NY_USA_Hacker wrote: post #55

Once a developer has done a project, he can give a good estimate of how long it would take for him to do that project again! Really, it's easy for developers to estimate time much the same way plumbers, carpenters, auto body shop workers, general contractors, dentists, etc. do: When a developer has done a very similar project more than 10 times recently, they can give a good estimate for how long it will take to do t…

Except that no two projects are ever really the same. Even with a very similar project you'll have different people, different systems to interface with and different scope.

Plus, any developer worth their salt will have built libraries as they went (or documented the existing ones), so the next similar project will take much, much less time.

Re: Why Can't Developers Estimate Time?

#69

Post by anthonyb »

michaelcampbell wrote: post #46
dennisgorelik wrote: post #36

Earlier quoted context omitted.

What you describe is, in essence, iterative development: Producing quick prototype and then fix it until it satisfies production needs.

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.

Re: Why Can't Developers Estimate Time?

#70

Post by jdavid »

charlief wrote: post #24

Lt. Commander Geordi La Forge: Look, Mr. Scott, I'd love to explain everything to you, but the Captain wants this spectrographic analysis done by 1300 hours. [La Forge goes back to work; Scotty follows slowly] Scotty: Do you mind a little advice? Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want. Lt.…

This might work in StarFleet, but the problem is that if you promise a manager something repeatedly, by overestimating, they will start to assume you are padding your results.

Having worked on scrum teams before, I find its a good structured way to have a dialog about how much work is left, and how long you expect it to take.

So rather than saying an hour. You would say this is as easy as changing a diaper, or its as hard as navigating through an asteroid belt at the speed of light ( having or not having done it ).

I would appreciate it if managers ask:

Have you done this before? (yes, no)

How similar is this to something you have done before? ( very similar, kinda similar, totally new )

What concerns you about the task, or what risks do you see coming your way? ( detailed answer )

What can I do to get you the resources you need to help you deal with the risks you can foresee now?

Post reply on HN