Why Can't Developers Estimate Time? • Hacker News Board

Re: Why Can't Developers Estimate Time?

#71

Post by jdavid » Fri, Apr 08, 2011, 3:36 PM UTC

ThomPete wrote: post #60

diegob wrote: post #54

Earlier quoted context omitted.

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."

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.

Re: Why Can't Developers Estimate Time?

#72

Post by wladimir » Fri, Apr 08, 2011, 3:39 PM UTC

VMG wrote: post #64

wladimir wrote: post #44

Earlier quoted context omitted.

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

On the other hand, in code styles, languages, idioms, a lot depends on taste. One person might find Lisp code ugly, another one might love it. Some person might find some library useful as a modular object oriented system, while someone else might find it a hellish heap of macaroni code.

Artists might like to experiment with different styles, so might coders.

Also, it's not like most artists try to sell people ugly things. That's also a very small niche. Most of them simply work for companies and design the things that they are told you. Just like coders.

We could debate about this for ages, but it seems very clear that there is both art and engineering involved.

Re: Why Can't Developers Estimate Time?

#73

Post by anthonyb » Fri, Apr 08, 2011, 3:42 PM UTC

HeyLaughingBoy wrote: post #63

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…

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.

Re: Why Can't Developers Estimate Time?

#74

Post by pmb » Fri, Apr 08, 2011, 3:42 PM UTC

Because they are doing something that has never been done before. The unknown is exactly that - unknown. You can make guesses, but they will never be anything but guesses until the problem has been solved a few times.

However, once a problem is solved, it does not need to be re-solved, and so the attention of the company turns to a new unknown problem.

Re: Why Can't Developers Estimate Time?

#75

Post by cosgroveb » Fri, Apr 08, 2011, 3:44 PM UTC

qntm wrote: post #17

allenp wrote: post #5

It's because developers are eternally optimistic. How else can you explain someone hitting a "compile" button a hundred times a day, hoping each time to get no errors?

Hey, sometimes I compile with the expectation of error, just to make sure that the right error comes out.

This reminds me of assembly language in college... Each assignment we were told to end the program on a different type of ABEND ("for this assignment I want you to generate a SOC8, integer overflow" etc, etc...)

Re: Why Can't Developers Estimate Time?

#76

Post by knodi » Fri, Apr 08, 2011, 3:45 PM UTC

I find that only bad managers ask "how long will this take you?" and idiot manager will take what ever time you give them and try to cut that short or judge time for the developers or engineers; like "this should be easy and will only take few day".

Good manager that have "developed" before will ask "how much work is left?" and "What are some of the out standing problems that need to be resolved?"

Look for the good ones avoid the idiots.

Re: Why Can't Developers Estimate Time?

#77

Post by nlawalker » Fri, Apr 08, 2011, 3:47 PM UTC

joezydeco wrote: post #52

Because estimates are not committments . http://cwd.dhemery.com/2003/08/estimates_are_not_commitments... "If you ask Fred, “When will you be done?” have you asked for an estimate or a commitment? What does Fred think you asked for? If Fred says, “Two weeks from today,” has he given an estimate or a commitment? What might happen if you want a commitment and Fred thinks you want an estimate? What might happen if you wa…

Oh man oh man, this right here.

I like to think of myself as someone who has a lot of common sense, but reading McConnell's "Software Estimation" made me feel like an idiot. He lays out the most important stuff right at the start of the book: an estimate is not a commitment is not a plan to meet a target. Reading this, I realized that where I work, the term "estimate" is often used to mean any one of those three things at different times, but most often is used to mean "commitment." Not knowing any better, I fell right in line.

McConnell's basic strategy for delivering an estimate (give a minimum, a maximum, and an "expected time") is great for so many reasons, but the reason I like it the best is for its communication value - by giving three numbers, none of them being an "I can have it done by..." number, you reinforce the idea that you are delivering an estimate and that the point of delivering that estimate is to help the project manager control the project. If it turns out that the PM is lazy and they really do just want a commitment ("sure, sure, whatever, when will it be done?!"), you can adjust your communication strategy accordingly.

Re: Why Can't Developers Estimate Time?

#78

Post by rch » Fri, Apr 08, 2011, 3:47 PM UTC

It is easier to estimate time for repetitive tasks, and (ideally) programming is not a repetitive task.

once something becomes predictable, it is probably also script-able.

Re: Why Can't Developers Estimate Time?

#79

Post by dpcan » Fri, Apr 08, 2011, 3:48 PM UTC

It's because programming is as much an art as it is a science.

You don't ask a painter how many hours it will take to complete a masterpiece. Nor do you ask a composer how long it will take to write the next great hit. Or an author how long it will take to finish a great book.

Sure, we can ask an artist to be done by "next Tuesday", or in 20 hours. And the artist will say, no problem, but there is no guarantee of quality.

Programming is no different. Yes, there is a method, a science, to getting things done, but when it comes to creating a finished work of art, it is not a time oriented task.

If you want quality, don't put us on the clock.

Re: Why Can't Developers Estimate Time?

#80

Post by ThomPete » Fri, Apr 08, 2011, 3:52 PM UTC

jdavid wrote: post #70

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…

Only when scrum is extended into the overall strategy of the company can it solve that problem.

It makes no sense if only the developers and designers are doing scrum when the rest of the company is expecting deadline deliveries.