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

51–60 of 173 posts

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

#51

Post by avmich »

crusso wrote: post #39
avmich wrote: post #23

Earlier quoted context omitted.

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

Developers, in my experience, are quite often asked to leave the company after such estimates. I've seen developers let go because they weren't very good at writing software. I've seen developers let go because they were painfully anti-social to the point that they were negatively impacting the rest of the organization. I have never ever seen a developer let go because their estimates were crappy.

Our experiences obviously differ. Usually it goes like this - the developer gives his best estimate (which is, by the way, hard by itself - a lot of things has to be taken into account), and that estimate is considered too high. So the developer is ordered - in one form or another - to, effectively, "do it faster". Often it's by cutting corners in places deemed least important - but then it also reduces probability of the correct estimate overall. One more thing - specifications are quite rarely are good enough - there are other reasons why that's the case - and the final result causes management to wonder, why it doesn't include this, of why that works this clumsy way. So nobody's happy - and developer pays the price. It may look as the developer isn't good at writing software... because "writing software" is a sort of encompassing figure.

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

#53

Post by wpietri »

w0rd-driven wrote: post #36
chris_mahan wrote: post #5

Because management looks at you funny when you say something simple will take 4 months. Then they lie and say that it couldn't possibly take that long. And the reason they lie is because there's no negative to them tying to you. Their job is to get you to go faster, and they are allowed to lie as part of their job, if it makes you go faster. The reality is that it doesn't make people go faster. It makes people leave…

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 point; something twice as big is 2 points, and so on.) Every week, you count up the points completed. That's your "velocity".

From there, you let managers do all the estimating they want to. If they want the complexity of a unit of work measured, they ask the engineers. If they want to know when X will be done, they look at the team's recent velocity, what's in the queue before X, and do some basic math.

The nice part about this is the mental judo involved. Whenever they want to know when something will be done, it's their problem to trade features against time. Working like this, it's not geeks vs suits; the suits channel their schedule pressure into productive work: grooming the backlog.

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

#54

Post by ataylor32 »

thirdtruck wrote: post #38
_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…

Have you shared these spreadsheets and lists online? They sound like something that could turn into an excellent, three-figure or more information project.

I, too, would be interested in seeing these. Here are some guidelines from somebody else that I found helpful, though:

http://www.missionfamilybank.org/software-estimating/

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

#55

Post by code_duck »

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

The hiking analogy works pretty well, extended to traveling in general.

I spent a couple of years traveling around to visit friends and family all over the US, and regularly my estimates were off in when I'd arrive somewhere. My software delivery estimates are similarly not perfect, in the later direction like most people. My conclusion was that my estimation of how long it takes to do anything is off a bit. For me, this is because I'm trying to say I'll do something sooner to meet the perceived needs and desires of others.

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

#56

Post by cs02rm0 »

crusso wrote: post #39
avmich wrote: post #23

Earlier quoted context omitted.

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

Developers, in my experience, are quite often asked to leave the company after such estimates. I've seen developers let go because they weren't very good at writing software. I've seen developers let go because they were painfully anti-social to the point that they were negatively impacting the rest of the organization. I have never ever seen a developer let go because their estimates were crappy.

You must have good customers then that value quality software over meeting deadlines. Not government I take it?!

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

#57

Post by dlitz »

The problem is that people try to eliminate uncertainty instead of trying to manage it effectively. If you're trying to make estimates with more than order-of-magnitude precision, then you're probably doing something wrong.

If we drove cars like we develop software, we would pre-calculate a list of instructions, set a timer, and then execute those instructions without regard to what's actually happening on the road. With practice, you could probably get better at making those lists of instructions, but why bother? The general approach is just ridiculous.

Decades of experience have shown that there is enough inherent uncertainty in software development that trying to plan everything from the start just doesn't have a high success rate. Even if you know everything that has to be done today to get the job done, your environment will change, and your stakeholders will change their minds. What good is software that perfectly solves the problem you had two years ago?

Once you dig through all of the buzzwords, "Agile software development" is simply about applying closed-loop control theory to software development: You structure your project to provide high visibility and to allow frequent changes in direction, then you iterate and make adjustments until the result is satisfactory.

Everything else generates unnecessary risks that somebody ends up paying for.

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

#58

Post by crusso »

wpietri wrote: post #44
_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…

I'm glad you got better at it, but I don't think software estimates can ever be very good. Nor should they be. That a project is estimatable has to mean that novelty is low and predictability is high. But low novelty is a sign of duplication, which should be factored out into things like libraries, frameworks, and self-service tools. High predictability is either a sign of duplication or it's a sign that people have…

First of all, don't overly aggrandize what we do. 99% of it is derivative in most ways. Although I've enjoyed doing the work on many of my projects, I'm not under any illusions that what I was doing was ground-breaking.

Besides, most of the things you mention can be accounted for. If part of your development process involves iterating through the design with the customer every couple of weeks then you build that into your estimates.

Likewise, I always build documentation and code handover support into any serious project rather than acting surprised that customers will want such a thing and expect it to be part of what I'm delivering.

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

#59

Post by alextingle »

avmich wrote: post #51
crusso wrote: post #39

Earlier quoted context omitted.

Developers, in my experience, are quite often asked to leave the company after such estimates. I've seen developers let go because they weren't very good at writing software. I've seen developers let go because they were painfully anti-social to the point that they were negatively impacting the rest of the organization. I have never ever seen a developer let go because their estimates were crappy.

Our experiences obviously differ. Usually it goes like this - the developer gives his best estimate (which is, by the way, hard by itself - a lot of things has to be taken into account), and that estimate is considered too high. So the developer is ordered - in one form or another - to, effectively, "do it faster". Often it's by cutting corners in places deemed least important - but then it also reduces probability o…

That's not bad estimating though. That's psychopathic management. The developer gives an estimate which is "too long" for the manager, who responds by essentially ignoring the estimate and laying down arbitrary deadlines. Surprise, surprise the arbitrary deadlines are missed, and the psychopathic manager blames the developer.

The developer's ability to estimate accurately is not an significant factor in this scenario.

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

#60

Post by RyanZAG »

kronholm wrote: post #31
_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…

Been going at it for a couple years now with consulting and freelancing. I've finally gotten good at hitting my estimates. What worked for me was to keep strict time of everything (shoutout to toggl.com, love it!), so I could learn from my mistakes. The trouble is now though, my competition seems to be underbidding me, but in reality they're providing those ~33% estimates they will never realistically keep, while I'm…

You're probably losing more business than you think - customers have no idea who is accurate or who is just faster, etc. They will generally go with the lowest quote regardless of other factors unless they've been burned before multiple times. Most people haven't.

I don't have a solution here though other than noticing that underbidding and then getting skilled at convincing clients to do paid extensions later actually appears to make the most money at the cost of your ethics. I'd avoid that approach, but it does seem to work for a lot of companies.

My personal approach is to quote for very bare projects with only the bare essentials (eg, poor UI design, minimum possible feature for the client to see what they're asking for, etc). This can usually be done a lot cheaper than most people think as 90% of the work is in the last 20% of the features. Then once the client has something, you can give them a quote to touch up the parts they need. Basically you split the project up into many small projects each with their own quote which helps you to estimate tasks as they appear and helps your client to minimize costs by leaving off features that are more expensive than they initially appear.

Post reply on HN