Hacker News Reader

Comment by dpweb | Hacker News Reader

At work, we are constantly hounded by non-technical business people for estimates. They want to time/cost box you. To them - you're an expense, and an expensive one.

My analogy would be someone asking how long it will take me to drive to my kids' school to pick them up.

70% of the time there is no traffic and takes 35 minutes. 25% of the time there is some wreck and takes 50-60 minutes. 5% of the time there is bad weather and very bad traffic and takes 60-80 minutes.

So, in your mind - most of the time it takes 35 minutes, and often the devs' answer is "35 minutes". This is where the experience comes in. The correct answer is.. 80 minutes.

I tend to accompy this (to the particularly ignorant non-technical manager) with various disclaimers about the 40+ year ongoing issue in est. sw development.

View on HN

That's the biggest danger with estimates, that you're being held accountable for a padded guesstimate. One way of avoiding this is to give estimates in ranges or with +/- attached:

"It will take 2 days, + 5 days, - 1 day" <-- that shows a lot of risk

"It will take 1-2 hours, + 3 hours - 0.5 hours" <-- again, showing that there's some risk

Or you push back and tell them to give you some time to form a better estimate or that you will give them an estimate update as soon as you know more.

The issue is that most software developers are not trained in how to estimate and in how to deal with these time/cost boxing scenarios. We don't attend a class like managers do on how to deal with situations like this. We have to learn as we go along.

I highly recommend Steve McConnell's Rapid Software Development, fantastic book, it has a chapter on estimation and how to deal with client's and boss's that ask for estimates.

He also has a whole book on estimation called Software Estimation: Demystifying the Black Art. It's a great read as well.

Bought it and recommended it to someone already, thanks for the suggestion!

In my opinion, if someone is asking you for estimates on 1-2 hour tasks, that person should kindly remove him/herself from the software development industry.

You could simply say, "I don't give estimates in under 3-hour increments, because there are inevitably other fire-extinguishing and support activities that interrupt even the most trivial tasks."

Sometimes I get interrupted with "Alice needs X added to Y right away", or "Bob needs reassurance that this is working as intended in the original ticket" -- no problem. Other times, one might lose productivity to things like, "Java update broke our GWT compilation toolchain completely".

It helps if your manager knows that such interruptions happen, too. I also am a fan of overbudgeting and then revising later once I understand the problem better.

This happens when people confuse estimates with deadlines.

I've had clients trying to negotiate my estimate downwards. So stupid. Why would you want to underestimate the actual needed time? You want to go over budget?

They want to negotiate your estimate down, so they can then pin your quote and budget to the lowered estimate.

"Going over budget? That's fine, let's renegotiate. Remember though that you're already behind on this project so that needs to be taken into account. We'd prefer this last leg of the project to be flat rate..."

It's definitely not right - and as a contractor your should read the tarot cards and have had preparations in place so it wouldn't happen - but you'd be amazed at how often variations of this scheme work out with PMs and procurement at larger companies that should really know better.

In this case, they were billed by the hour anyway, so no.

> At work, we are constantly hounded by non-technical business people for estimates.

They actually want you to tell them price. They just think that price is called estimate in IT world.

I try to clarify on each occasion that what I'm giving them is not a price, not even an actual estimate. I'm giving them just my guess about the future.

To get an estimate they need to apply some math to my guess, hopefully based on project history and other factors.

Full price will never be known because all actions bring in complexity into the system, that causes technical debt to grow by unknown amount.

Reply on news.ycombinator.com