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

Why are software development estimates regularly off by a factor of 2-3?

michaelrwolfe.com

Post reply on HN
Print view View original

91–100 of 173 posts

Re: Why are software development estimates regularly off by a factor of 2-3?

#91

Post by smokey_the_bear »

We sometimes make white label geo apps for other companies. We've repeatedly had problems where our estimates were off by quite bit because we got data in incredibly bad formats from the customers. And not just once, every time they'd send us updated data it would be in a different format.

The first time or two it made us hate the customer, and feel like it wasn't our fault. But then we started writing it into the bid, and telling the customer they could save money if they delivered conforming data. Hopefully we'll be happier from here on out.

Re: Why are software development estimates regularly off by a factor of 2-3?

#92

Post by eftpotrm »

Well, yes, but also (stretching the analogy) how many times have we been asked for a schedule to an unnamed destination via unspecified waypoints and then told it's too long and we need to make it shorter?

Devs make mistakes, sure, but as often as not in my experience it's absurdly vague end user requirements married to unrealistic expectations.

Re: Why are software development estimates regularly off by a factor of 2-3?

#93

Post by jroseattle »

avmich wrote: post #23
_wwz4 wrote: post #18

So the article tries to describe the hidden complexity of software with a hiking analogy but then it leaves a huge part missing. Let's extend the analogy somewhat... this isn't your first hiking trip. In fact, you've been on dozens and dozens of hiking trips. You're an experienced hiker. Yet, why do you continue to give meaningless as-the-crow-flies estimates of how long it will take you to get to your destination? T…

"Developer estimates are regularly off because they seldom impact the developer directly." I think I most disagree with this. Developers, in my experience, are quite often asked to leave the company after such estimates. It's good to have a template - it helps not to forget things - but it is inherent in the work to have unknowns. Large unknowns. A good consultant would probably refuse to work on a project which woul…

"Quite often"? Really?

Frankly, I would expect such a company that employs those practices sees two things:

1) A very low retention rate among employees, with a lot of churn.

2) A risk-averse organization, heavily skewed to under-promise and just-enough over delivery.

Re: Why are software development estimates regularly off by a factor of 2-3?

#95

Post by antonwinter »

when asked to estimate, i ask if the biz if they can also give me an estimate for meetings, UAT, changes, hiring resources, unscheduled downtime and scheduled downtime and historic data comparing previous project estimates to actuality. Its the only way to get closer to accurate.

The developers estimates generally are best case scenarios without any external or motivational factors included.

Re: Why are software development estimates regularly off by a factor of 2-3?

#96

Post by rquantz »

_wwz4 wrote: post #18

So the article tries to describe the hidden complexity of software with a hiking analogy but then it leaves a huge part missing. Let's extend the analogy somewhat... this isn't your first hiking trip. In fact, you've been on dozens and dozens of hiking trips. You're an experienced hiker. Yet, why do you continue to give meaningless as-the-crow-flies estimates of how long it will take you to get to your destination? T…

Would you be willing to share these checklists you've created? I would be curious to see them.

Re: Why are software development estimates regularly off by a factor of 2-3?

#97

Post by 11thEarlOfMar »

If you can suspend the obvious question of why are you hiking from San Francisco to LA in the first place, the general analogy holds quite well: With software development, you can not know how long it will take until you know exactly what you are building. You can not know exactly what you are building until you have fully described it. The act of describing it fully, precisely and with sufficient quality, is the act of coding.

Hence the completion estimate has to be continuously refined as the details of implementation are continuously refined.

Just like the slow zoom-in on the hike.

Re: Why are software development estimates regularly off by a factor of 2-3?

#98

Post by mentos »

rdtsc wrote: post #24

Good points in the article. You can think of it this way. A coast line is a fractal line. As you zoom in its length gets bigger and bigger seemingly. From the top level on the map it looks fairly straight. Related to estimates. Programmers have and operate with idealized mental models. A FIFO queue works kind of like this ("/closes eyes and sees a line of people lining up at the store"), a tree traversal looks like t…

I think the fractal analogy nails it.

Haven't thought about it before but I realize I too use a heuristic of x2 or x3 when estimating my time. Nothing would stop me from getting a pen and paper out and stepping through the 'trail' in my head in pseudocode beforehand, but for most of my projects I'd benefit from just writing the real code from the start and apply the time I saved to the project.

Re: Why are software development estimates regularly off by a factor of 2-3?

#100

Post by w0rd-driven »

wpietri wrote: post #53
w0rd-driven wrote: post #36

Earlier quoted context omitted.

Management giving estimates? No thanks. I'd rather them take my input and do their job of understanding trends. When I say something takes a long time and it takes longer, I'm not bullshitting. When I think something takes a long time and doesn't, its generally because shortcuts are rarely understood up front. Will I find the same shortest path next time? If I'm doing the same exact work maybe. I do work in a place w…

> Management giving estimates? No thanks. This is actually achievable in a sane way. I have done it using the XP planning practices. Basically, you make the suit break everything down into relatively small lumps and place them in priority order. Every week, the team completes a few lumps. Before you do them, engineers grade their relative complexity in arbitrary units. (The smallest substantial thing you do is 1 poin…

I misspoke. What you are describing comes from developer feedback but indirectly in a sense. This, I think, is a nice standard of measurement. Its when people solicit absolutely no feedback either in the form of past projects where hours are measured somewhat or what they just "feel" something should take. I'm all for metrics based estimation because that's how most developers would likely estimate. Its when management seems to pull things out of their ass to get a prospective client I have a problem with. I understand when we need money but I can also trace some of our worst clients to some of the most unrealistic estimates we've ever given. They're almost a 1:1 direct correlation and its like no one sees how much of a drain they can be all around.
Post reply on HN