Hacker News Reader

Comment by tyingq | Hacker News Reader

Guessing this won't be a popular response, but all the hand-wringing about how management is unreasonable to ask for estimates (cost or time) just isn't helpful.

Anything a business is going to invest in needs some kind of justification, and a metric to prioritize against other things the funds could be spent on.

I think it's fair to push back with suggestions that might make a realistic estimate possible (reduce scope, proof of concept, etc). However, just suggesting you can't provide any kind of reasonable time and cost estimate doesn't help anyone.

View on HN

I agree that businesses need estimates, but the problem is the form they take. It's always "2 weeks", or maybe at a better place it'll be "2-3 weeks" both of which are basically lies because they imply high confidence. What it really ought to be is "2 to 3 weeks with X% confidence" because there's an absolutely massive difference between "2 to 3 weeks at 90% confidence" and "2 to 3 weeks at 10% confidence and at every place I've ever worked they both get treated the same. The 10% confidence one might be roughly equivalent to "2 weeks to 6 months" with an implied high confidence but good luck giving an estimate with that kind of range.

That seems completely reasonable, and provides what a business would want...metrics to make decisions on where to spend money.

The tack of the article was "Estimates can't be done". Which is silly. It presents this analogy: "would it really have made sense to ask Einstein how long he would take to find a unified theory of physics?"

I'm sure there's some small amount of software work that might fit in that space. I would also guess that the vast majority of it doesn't.

Yeah, I find the optimal balance between simple numbers that find traction politically, and the realistic but unpopular acceptance that things are uncertain is a triangular distribution "least possible, greatest possible, most likely".

You can plug these into monte carlo simulations with any kind of math happening between your uncertain terms, get output distributions, pick bounds to minimise risk (95% chance the release is completed on or before <DATE>).

Reduction in scope and prototyping can help reduce risk in how wrong your estimate is, but I think it is misleading to suggest that these techniques inherently "might make a realistic estimate possible." I don't think I'm alone in that I've had tasks that were supposed to take less than a day take weeks. I'm not saying this is common, but there is no silver bullet, and assuming from the beginning that estimating is basically impossible can help bring everyone into reality.

I'm not suggesting scope reduction or prototyping are magic solutions. I offered them as 2 examples of constructive pushback.

The essence of my point was that flat out not estimating isn't an option.

It is for some companies. Or just do very crude estimates like "this might take 3-5 weeks" even for things that might take 1 week but could take 6 weeks.

Sometimes it is better to start developing and then tell stakeholders that it will take a really long time when you run into problems. A lot of stakeholders have problems with estimates of the form "it could take 2 days or 3 weeks". It would be nice if the industri starts giving probability about estimates especially when you know that there are two clear possibillties where one is much, much larger. They might want to invest 2 days into trying to solve the problem with the understanding that it might take much more time and if that happens they can change their mind and skip the feature instead, "only" wasting two days of investigation.

But it can be. See "Wake me when it's over".

You can commit to an investment with no idea, at all, whether it will cost more than the benefit it delivers. I suppose "not an option" isn't quite the right wording. It's an option.

That's not what it means. You have to be diligent in asking properly and vetting the rules for what's to be done. It may also include gate meeting type things and regular status reporting. You just don't downshift the project into high torque when some phony date rises up.

I don't remember if it's "Mythical Man Month" or Thomas deMarco where I'd read it. They're better at explaining it than I.

But it's temporary state that will affect behavior and make things permanently worse - not just for the developer, but for everybody. Getting it wrong can inflict mortal blows on the enterprise. Having the power players escalate based on status will make it oh so much worse.

People need to understand that there is no zero-cost instrumentation and getting measurement wrong is extremely expensive.

I have to work backwards from deployment to development or there are problems. Sometimes there are external lags of months between them. People find my line of questioning in this regard very annoying but I do this and others on the team/teams do not, and I have a much better accuracy rate. So they've learned to do this with me.

When you're deploying, you're designing a protocol and that's always a challenge. But if you don't do it, the error rate creeps up.

I publish a statement of work for each release point and encourage redlines to that. So far it's not drawn any fire. But inadvertently getting a feature in before it's handed off properly causes lots of problems.

The critical resource is always human attention.

I still think you need some kind of estimate. At the very least, you should have a high level of confidence that "what I'm spending to get this" is less than "what value it will deliver".

Of course, if you can't be more precise than that, chances are that there's some other piece of work that's more easily estimated, and has a more concrete ROI. That work would logically come first.

Here's the problem. Management is going to make decisions. That's part of their job. They aren't psychic. As you say, you need some kind of an estimate (or at least, management needs you to give them one).

But there are times when you don't know. So you handle that by saying something like "I don't know enough now to give you any kind of an estimate. In a month, I'll be able to do enough research that I can give you a realistic estimate." If management will accept that, congratulations! You have management that is willing to live in the real world.

But you can't even always do that. I was asked to estimate how long it would take to port something I'd never had to touch before. Well, I don't know. Worse, I don't know how long it will take me to find out, because I don't know how many obstacles I'm going to hit, or how long it takes to get past each obstacle. I'll know when I'm done; I don't know any more precisely than that. I mean, I can say something like "probably less than a year", but I have no idea how to do better in that situation.

It is generally the truth, though. I can't tell you how long it will take, because I don't know, because I've never done it before.

If I've done it before, or something enough like it that I actually could tell you how long it would take, then you are wasting your money and my time by asking me to repeat the work.

If you hired me because you wanted me to do the same thing for you that I once did for someone else, and you therefore expect me to be able to tell you how long it is going to take, then I will start polishing up my resume, because I made a mistake when I accepted your offer.

That's fairly personal, down to the "you" level.

What I'm saying is that it doesn't matter if it's a software project, construction project, etc. If the potential amount is non-trivial, it's bad business to commit to a completely unknown amount of spend.

If you can't say that the spend < benefit, you really shouldn't do the work. It's basically speculative investment at that point.

That may be something you personally aren't on the hook for. But, in most cases, there's some option to get an idea. Bids from outside software development shops, calls to companies you partner with, small scale prototype, agreement to spend a fixed amount and re-evaluate, etc.

It very much does matter if it's a software project or a construction project, because the essence of a software project is that it involves an exploration into the unknown. If it were a routine process which could be estimated accurately, we'd have automated it already, and we wouldn't need to estimate it because we'd simply delegate it to a machine.

Software is nothing like construction. We don't build bridges, we draw blueprints for bridges, which our construction robots then build overnight; if it's a good bridge, millions of other construction robots go build millions more bridges just like it. If the bridge doesn't work, we have the construction robots tear it apart, and we try again with another one the next day.

When we get good enough at designing bridges that we start to see the patterns involved, we build a robot that draws bridge blueprints, and we have the blueprint robot tell the construction robots what to do while we sit around and think about urban design theory. When we get good enough at thinking about where bridges ought to be placed and what attributes they ought to have, we build ourselves a highway-design robot that orders around the bridge-blueprint robot that orders around the construction robots, and then we move on and start thinking about something more interesting.

Software is basically speculative investment. That is why we make the big bucks when our projects succeed.

some software is speculative investment.

edit: fwiw, construction projects often touch on "exploration into the unknown".

Also, you are arguing against "accurate estimation". I'm arguing against the premise of the article. "No kind of estimation is possible"

Edit. Nobody is asking for made up numbers. They are typically asking that engineers participate in a reasonable discussion to try and get some criteria to make a decision. "I couldn't even say 1 week vs 10 years" is just as silly as "I want an exact number".

Sure, and to the degree that they do, they can't be accurately estimated either.

... Even if the words people are saying sound like "We want to build this; how long will it take?", the process which actually happens is "We have this much money/time, and we want to solve this problem; what can we build in the time available?" To the degree that people believe they are operating in the former mode, sadness happens, because software engineering is actually about the latter.

Well, okay, sure, if you want me to make some numbers up, I can do that. Just understand that you're not actually asking me to estimate the time a process will take, you're asking me to make some numbers up so that you can convince yourself to feel good about the speculative investment you're making!

Edit: we've apparently had different experiences around the word "estimate"; for me that's always been a term used by managers who want something they can slot into a Gantt chart or its equivalent, and trying to play along with that game has always led to frustration. The people in my experience who have been looking for "some criteria to make a decision" haven't generally called the information they're looking for an "estimate". The processes which have actually worked, in my experience, don't start with tasks and try to generate a schedule which fits: instead, the process starts with a schedule, and the engineer's job is to figure out what can be done in the time available and how most effectively to make progress within that framework.

Even more so, there is an analogy to construction in software, and it has been possible to fully automate it since decades with tools like make, ant, etc.

Yes, I agree. We can estimate. Sometimes the estimates will be wrong, but that's life.

Reply on news.ycombinator.com