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

121–130 of 134 posts

Re: Why Can't Developers Estimate Time?

#121

Post by jongraehl »

ThomPete wrote: post #35

Time estimations is an industrial way of thinking applied to a post-industrial world. In the post industrial world time isn't the problem but rather project definition and scoping. In the industrial world the problem was already solved (machine was built, market often established and output depended on a few factors that could be adjusted. Need more output add more of X) In the post industrial world every project is…

Actual effort to complete can be quite surprising, but effort spent per day also varies tremendously. For example, when things are going well, there may be a burst of joyful effort.

Re: Why Can't Developers Estimate Time?

#122

Post by [deleted] »

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

[deleted]

Re: Why Can't Developers Estimate Time?

#123

Post by jacques_chester »

ThomPete wrote: post #59
diegob wrote: post #42

Earlier quoted context omitted.

What could replace it?

That is hard to say and it would be a book worthy to explain what could come next. All I know is that it is unsustainable. The complexity is simply too high and it's not getting better. One of the reasons I think why you see the fail fast movement be so successful. Once you accept that failure is part of the process, once you abandon the "zero mistake" policy that many large organizations instill internally and exter…

I think you will find reading Hayek and Coase to be rewarding.

Hayek introduced the idea that no one individual planner can make flawless plans because the information to do so is widely dispersed; instead success or failure in the market gives rapid feedback about how to allocate resources. Indeed the market is a discovery process that unearths this information in a way that a planner never could[1].

Coase asked the question: if this is so, how do large firms emerge? He identified the cost of transactions to be the key. The higher the transaction costs, the higher the cost of loosely coupled economies. The size of the firm is thus based on the relative costs of transactions (searching, identifying, validating, negotiating etc) vs the inevitable waste caused by planning.

In essence, large companies are islands of command economics in the sea of the market.

[1] In a related argument, Mises said that even if a planner could know all the variables the resulting problem would simply be too large to solve rationally.

Re: Why Can't Developers Estimate Time?

#124

Post by jacques_chester »

netghost wrote: post #94
diegob wrote: post #42

Earlier quoted context omitted.

What could replace it?

Instead of replacing estimation, I would say that you should embrace the problem in estimates - uncertainty. Convey the uncertainty you have about a task to those you work with, and then you can start to factor in the risks of uncertain tasks. I build project management software for a living at LiquidPlanner. Everything we do be it development, design, or marketing is based on ranged estimates. We don't always get th…

I absolutely agree that interval arithmetic is the best way to deal with this, accountants and their budget systems always require estimates to be reduced to fix figures.

Re: Why Can't Developers Estimate Time?

#125

Post by redthrowaway »

Natsu wrote: post #107
PaulHoule wrote: post #49

A big part of the problem is that management often isn't interested in honest estimates. You can certainly find better practices in some organizations, but in many organizations, a certain team gets tasked with completing a certain assignment by an arbitrary deadline and no attempt is made to reconcile the triple constraints with reality. In a context like that, developers may not be asked to make estimates, and if t…

> The good news for both developers and managers is that estimation is a learnable skill. If you get in the habit of making estimates and testing them, you'll get better amazingly fast. See the classic book It's not hard to learn to make reasonable estimates. Even for unknown problems, I can often say that X has usually taken about Y time in the past and be right most of the time. The real problem comes when the esti…

Or when you're tasked to do something you've never done before, and your initial thoughts of "I bet y is like x" turn out to be terribly wrong.

Something so seemingly trivial as a different API can make two similar tasks take vastly different amounts of time, especially if you're approaching the second problem with the mindset induced by the first API.

Re: Why Can't Developers Estimate Time?

#126

Post by knodi »

Natsu wrote: post #118
knodi wrote: post #76

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 o…

You're right that managers who understand your job can make life a lot easier. But this goes both ways. I find that understanding what constraints my management is under can help me to help them plan. When you understand what their problem is (e.g. we promised X to the client and we have to make it work somehow), you might be able to rearrange things to make that possible. Of course, an ounce of prevention is worth a…

Very true and there is a very easy way to do this. Be your own boss.

lol

Re: Why Can't Developers Estimate Time?

#127

Post by jclaassen »

zedshaw wrote: post #101
jdavid wrote: post #70

Earlier quoted context omitted.

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…

> the problem is that if you promise a manager something The real problem is thinking of "estimates" as "promises" when really they're rough guesses. If you go around holding people to a guess as if it were some kind of gospel biblical contract then yes, they will lie their ass off to protect themselves. Combine that with the fact that most organizations attempt to control the platform used, computers used, monitor s…

Managers want promises because execs need promises because the board is critiquing their job performance based on when they ship the next product.

The board wants promises because they want to know when they get paid.

If you find it stressful that people are turning your vague estimate into a promise, imagine having to make promises on other people's vague estimates.

Re: Why Can't Developers Estimate Time?

#128

Post by EdiX »

VMG wrote: post #41
wladimir wrote: post #30

Earlier quoted context omitted.

I do agree with him. In my opinion, software development is exactly a creative process. Many times, you have to come up with a creative solution that fits within certain constraints. Also, in the beginning usually only a vague image is known. The artist (developer) has to fill this in and make sure it is what the client wants. Also, many creative works are collaborative efforts as well these days. I'm not sure how th…

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.

No one will buy a skyscraper design that has no doors or windows and crumbles under a breeze. Architecture and industrial design are two examples of things that need to cater to practical needs yet are usually regarded as forms of art.

Of course there's also people who think that art is only art if it doesn't do anything and isn't "needed". This also creates problems (for example, can a movie be art? if yes what of the "jobs" needed to create the movie are art? who are the artists?)

Re: Why Can't Developers Estimate Time?

#130

Post by anthonyb »

michaelcampbell wrote: post #83
anthonyb wrote: post #69

Earlier quoted context omitted.

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 uni…

The 'right' answer there is to system test first (eg. set up a dev system and run things like selenium against it) and then you can start to pull stuff out into libraries and unit test it.

The standard way around the 'luxury' attitude is to start with fixing downtime, and grow from there.

Post reply on HN