Hacker News Reader

Comment by BurningFrog | Hacker News Reader

> The business wants to know how much feature X is going to cost and when they can expect it.

Of course they do. We all want things that are impossible to have. I want to know the AAPL stock price in 6 months.

The traditional way to manage this impossibility is that engineering lies about it (they have to lie, because they can't know either), and once people are lying to each other, trust is unlikely to arise.

The agile concept of "velocity" is the best way I know of managing this. It's not very good, and it's often a victim of Goodhart's law.

View on HN

It's not impossible to estimate roughly how long something will take.

If you consistently get it wrong, either:

1. You're not breaking down the work into small enough chunks to properly think about how long it will take

2. You are probably consistently under (or rarely over) estimating and should be able to fix that. For me, I have to triple my estimates, it always takes 3 times longer than I think it would

To claim estimating is "impossible", when many of us do it absolutely fine, is ludicrous.

Separately, there's scope creep, but that's another matter and again can be managed (e.g. "if you want X extra functionality for the same cost, you're going to have to drop feature Y, which will take roughly the same time").

Advocating process solutions over people solutions is precisely non-agile. If people are burning out, then you need to address that.

Estimation is hard. Accurate estimation is even harder. Doing it in the face of noon stationary scope is a fools game.

Who is in charge of estimating how long it will take to correctly break down a problem into accurately estimable sizes?

It doesn't have to be accurate it just has to be order-of-magnitude right. We're talking about a rough estimate of how much feature X costs.

If something costs 15k instead of 10k, that's understandable, if you estimated 10k and it ultimately costs 1.5 million to develop, obviously not.

50% off is understandable ? Where can I find such forgiving clients? My clients lawyers would eat me alive if I would start to bill them in such manner. They dont want to hear about uncertainty - they are buying professionals and this kind of estimations looks to them like we dont know what we are doing.

Maybe if you're building the nth monitoring dashboard or something. The work I find interesting is inherently uncertain, though.

Sure we all know this, but for business people with money this looks fishy. This xkcd sums up the problem perfectly: https://xkcd.com/1425/

How non technical person can tell the difference between task inherent uncertainty and Your incopetence? They cant that's why they will buy Your competition that will claim there is no uncertainty.

Initial estimation (over many sprints, with either a greenfield project or with a new dev team) is always very hard, almost a completely foolish attempt.

After the first few sprints the uncertainty reduces.

And after the team gains experience with the system (business domain + codebase + infrastructure - if applicable), they are much better at scoring tickets (SCRUM poker), which then can be converted back to time from points.

Directly estimating time (asking for time estimate from programmers) is just something that never works (or if it does, then it means the programmers does the following adjustment internally), as humans get into the confusion of constantly having to recalculate their intuitive feeling of required time based on how long actually that took the last time they felt that.

I've seen Agile™ estimation break down when the task is either 1. something nobody has done before (or has no close analog), or 2. is so interconnected that it can't be broken down.

The former is just a matter of hiring more experienced engineers _or_ allocating exploratory/prototyping time. Still high uncertainty but these kinds of tasks become rarer over a time.

For the latter, the common refrain is "break it down" but there certainly exists a relatively common type of work that must be completed all at once. And I find it increases as the complexity or popularity of the product increases, so with time. Therefore perhaps the metaphor of building becomes less appropriate, and surgery paints a more accurate picture.

Builders can construct a house, then add a garage, go work on another house, then return and add a guest bedroom, then remodel the kitchen, all with relatively minimal pausing or switching cost. But once a patient is put under and opened up, the surgeon really should work on finishing up that one patient before moving on to the next one. And for some weird reason we tend to prefer one big surgery to multiple small "atomic" ones.

> Builders can construct a house, then add a garage, go work on another house, then return and add a guest bedroom, then remodel the kitchen, all with relatively minimal pausing or switching cost.

Have you worked with contractors? This is so so so so not true.

I don't know. We see quite a few (civil) engineering project that are ~on budget. A few that are wildly over.

But the thing is, in software engineering - if you ever need to do again, something you have done before, it should be just a copy away.

So you'll never spend time on something you've done before. And if you do, that time is essentially wasted - something that shouldn't be billable.

Now that's the ideal, obviously - reality is a bit more nuanced.

> And if you do, that time is essentially wasted - something that shouldn't be billable.

If I develop a feature for company A, then reuse it for company B, isn't A footing the bill for B? I mean, we all do that, but I think it's worth thinking about.

It might be billable to comp B (they got the value add), but internally that should not have high cost (in hours, resources) attached.

Ed: that is to say the time is wasted - but might very well be able to charge a premium on the experience. In my original comment I was mostly talking about making feature x for customer a, then making feature y for customer a. Where x and y are pretty much the same.

That's the problem. In theory every bridge is the same. Yet you need to plan each one of them.

Similarly every run of the mill business-as-usual boring-as-fuck CRUD corporate internal "app" is the same, yet they still need a lot of work, and they are still hard to "estimate".

> 1. You're not breaking down the work into small enough chunks to properly think about how long it will take

This usually means prototyping, which means actual coding, which means you couldn't do it as you already had to give your estimation. To put it another way, places who require estimates for planning want them during planning and don't allow time for doing this. On the up side, when they do let you take the time to prototype they take your prototype and put it right into production because then the estimate is 0.

> 2. You are probably consistently under (or rarely over) estimating and should be able to fix that. For me, I have to triple my estimates, it always takes 3 times longer than I think it would

This is a common trick but it really just means you are not really estimating, but guessing that it will take less than this amount of time. This would be more apparent if you gave an estimation range, what you actually estimated to your estimate times the 3X padding.

> If you consistently get it wrong, either:

> 1. You're not breaking down the work into small enough chunks to properly think about how long it will take

This is exactly what waterfall was. It pre-planned all the small tasks beforehand and required stopping the world and replanning everything when something changed.

Agile was an attempt to move away from that and create a feedback loop where you do some limited work, learn something from it, and then do another thing after you've internalized what you learned. (Original "sprints" were a coordination mechanism between departments that was applied in the automotive industry: there was lots of dead space in-between them). The whole point was the iteration was small enough that it didn't actually matter if your estimate was correct or not.

This bastardization where Agile has become synonymous with estimation accuracy is completely against its original spirit. People have started to care about estimates because Software Project Managers wouldn't have a job if there wasn't a need for heavy-handed planning sessions.

I think the estimation accuracy is not the main point nowadays, but instead the simple fact that the viability/rentability of every project matters, and even if there's an up front pile of money to spend (quarterly/yearly budget), there are probably multiple competing ideas on what to spend these - and of course these usually consist of and involve software and its development.

Of course this is why having a low-fluctuating empowered team (project ownership, refactors, etc) can usually deliver changes faster and with lower cost and with greater consistency, than every time doing a new project (which might involve new people who never saw the stack, nor the business domain) to modify something on a system.

> To claim estimating is "impossible", when many of us do it absolutely fine, is ludicrous.

How do you do it? I mean, how do you know when you reached the necessary granularity? And even if you know, sometimes it just means more questions that the client might not be able to answer at that time. Do you come up with a worst and best case and carry that delta up the breakdown hierarchy of components? Are you able to do this for every kind of task that can come up in a project? (From frontend design to backend implementation and third party system integration and infrastructure setup and then product deployment.)

And velocity should be an internal team measurement not shared with outsiders because (Goodhart's Law) when management says "Let's increase our velocity" and the team and developers are GRADED/PROMOTED on their velocity then you'll get point/estimate inflation which will hurt you more in the long run since the inflated estimates actually now allow for the work to fill the time (Parkinson's law).

> The traditional way to manage this impossibility is that engineering lies about it (they have to lie, because they can't know either)

Honest estimates with uncertainty are not lies, and not having certainty doesn't prevent estimation.

But, yes, people seem to often decide that being uncertain justifies self-serving lies instead of honesty (and sometimes the environment encourages that by punishing honest estimates.)

Engineering does not have to lie. All this takes is design and specification upfront, a well-defined feature set, and room for error.

Also, avoiding scope creep is paramount.

What's the usual processing speed of a software engineer when it comes to reading through and understanding design & specification?

We found that usually either the documentation/specification/requirements are too fine grained (and then they then change all the time, but then there's no real effort/bandwidth to do change management on the specs), or they are not detailed enough, which makes the estimation process a useless guessing game on what might they mean by this or that.

See, I would expect the engineers to pipe up and explain that. It takes collaboration to get it right, and it takes the engineers setting expectations properly for what they need to estimate accurately.

It’s a collaborative effort, not a one-way street, as with most things.

“Walking on water and developing software from a specification are easy if both are frozen.” - Edward V Berard

Reply on news.ycombinator.com