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

91–100 of 134 posts

Re: Why Can't Developers Estimate Time?

#91

Post by vermasque »

bsaunder wrote: post #23

Almost all bad estimates are due to a lack of information. In software development, the information that tends to be missing are the particulars of the task being estimated (which code needs to be modified, in what way). This missing information is highly unique and not to generally transitive from one programing assignment to the next. Additional information about the process is usually not the problem. Things like…

Speaking from experience at a large multi-year project at a BigCo, I am quite familiar with the failures of estimation. Some information is absent because some things are simply unknown due to inexperience or inability to predict future changes or mistakes (reasonable). However, other things are lacking because there is no motivation or demand to produce them. For example, waterfall processes generally throw the software development lifecycle on a schedule for a system or subsystem: requirements, design, implementation, test. If the lifecycle stages are not divided into tasks upfront (which then should be further divided), then the complexity of each stage is basically not being factored into the estimates for each stage. This is setting the stage for failure unless it is a project that has been done repeatedly over many years in the organization.

Furthermore, continuous process improvement and monitoring is not done enough even in organizations that declare achievement of higher levels of CMMI. Our team had subsystems that overran their initial estimates by over 100%, causing nearly a year in delay. However, there were basically no penalties or major process changes despite the fact that multiple subsystems overran estimates multiple times. Process professionals, engineers, and managers are simply not aggressive in tackling these problems.

In addition, estimates tend to come from individuals. I imagine that a more collaborative team-based estimation approach would be better, factoring different levels of experience and sharing the burden of making estimations realistic. Also, recorded estimates need to be coupled with recorded justification.

Re: Why Can't Developers Estimate Time?

#93

Post by mbesto »

This goes for everything in life. Humans suck at planning.

EDIT: http://book.personalmba.com/planning-fallacy/

“Hofstadter’s Law: it always takes longer than you expect, even when you take into account Hofstadter’s Law.” — Douglas Hofstadter, cognitive scientist and Pulitzer Prize–winning author of Gödel, Escher, Bach: An Eternal Golden Braid

Re: Why Can't Developers Estimate Time?

#94

Post by netghost »

diegob wrote: post #42
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…

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 the estimate right, but that's the beauty of a range, I it takes into account the fact that you will miss it some of the time.

The other thing that can replace an estimate is... lots of estimates. If you're planning something, update your estimates as you gain more knowledge about the problem.

Re: Why Can't Developers Estimate Time?

#95

Post by netghost »

jospehcanto wrote: post #27

Want to hire the most experienced programmer out of a group of candidates? Ask them to estimate a programming task, then pick the one that gives the longest estimate.

I'd say hire the one that gives you the best justification for their estimate. It's important for people to understand what is and is not involved in an estimate as well as why they think something is hard.

Once you communicate that, you can uncover a lot of potential problems and misunderstandings. For instance just the other day my co-worker was asked to estimate a task that seemed to our boss to be pretty small. He estimated it as being 2-8 days, it wasn't until they actually started talking about _why_, that they both agreed on the requirements. The resulting task will probably take 1-3 hours.

So sure, as a developer learns more they may estimate tasks as being longer, but communicating your assumptions is more important than throwing out huge estimates to cover your ass ;)

Re: Why Can't Developers Estimate Time?

#96

Post by bendtheblock »

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…

It sounds like you've thought deeply about this - have you written more on your ideas here elsewhere? Would be interested to hear how this would work practically as well as your ideas on how the focus on perpetual growth hinders successful project delivery.

Re: Why Can't Developers Estimate Time?

#97

Post by run4yourlives »

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'd love to see you write more on this as well. You've clearly thought about it prior to this conversation in a way that I don't think a lot of us have.

Re: Why Can't Developers Estimate Time?

#98

Post by [deleted] »

bendtheblock wrote: post #96
ThomPete wrote: post #59

Earlier quoted context omitted.

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…

It sounds like you've thought deeply about this - have you written more on your ideas here elsewhere? Would be interested to hear how this would work practically as well as your ideas on how the focus on perpetual growth hinders successful project delivery.

[deleted]

Re: Why Can't Developers Estimate Time?

#99

Post by [deleted] »

bendtheblock wrote: post #96
ThomPete wrote: post #59

Earlier quoted context omitted.

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…

It sounds like you've thought deeply about this - have you written more on your ideas here elsewhere? Would be interested to hear how this would work practically as well as your ideas on how the focus on perpetual growth hinders successful project delivery.

[deleted]

Re: Why Can't Developers Estimate Time?

#100

Post by bugsy »

Accurate estimation is certainly possible and is practiced by professionals, I do it myself. It's a skill though and it requires ground work in advance. Those interested may find discussion of some methods in McConnell's "Software Estimation: Demystifying the Black Art". Humphrey's PSP materials are an earlier but useful source of information.

The skill is irrelevant in most workplaces though. In most cases time to do an estimation is forbidden, and in the rare cases where an accurate estimation is produced, it is replaced with management's wishful-thinking estimate instead, which insecure developers are often strong-armed into "agreeing" to.

Replacing an accurate estimate with wishful thinking and whipping the slaves to go faster does not mean accurate estimates are impossible. It means that there is a problem with endemic management incompetence and unprofessionalism throughout this industry. If you have not established a track record of accurate estimates, you shouldn't be managing in any capacity at all. I don't expect this to happen though. I fully expect incompetent unprofessional management to continue to be the rule throughout most of the industry because there is little sincere interest in fixing things compared to maintaining empires ruled by fools. The preferred system is of blaming developers for bad estimates that were forced upon them by management, or that were produced by people who have no idea how to estimate and who are given no tools or training in how to do so.

What a relief it is not to be working for such incompetent management and be on my own. To those whose bosses are bullying them into giving bogus estimates and then blamed when things go wrong, you have my sympathies.

Post reply on HN