Hacker News Reader

Comment by hliyan | Hacker News Reader

The disdain for estimates in some of the comments here indicate that there is an organizational problem in the way those estimates are solicited, rather than a problem with the idea of estimating work itself.

I used to work for an organization where engineers so universally loathed the idea of estimates that I was convinced that it was just a necessary evil. But a few months ago I joined an organization where the relationship between engineering (which I'm in) and business is not very adversarial. Here, estimates are a tool to answer the question "how much work should we take up in the next sprint without burning ourselves out?". The estimation process is not loved, but it's not hated either.

View on HN

1) Most of HN is young and has never worked on the business side of an org where they had to do things like lose a customer because the feature they wanted is taking too long to finish or repeatedly push back multiple expensive dependent non-engineering projects because engineering keeps hitting development roadblocks.

2) A lot of developers really hate committing to any kind of estimate because they're really just not that good at estimating for a variety of reasons and getting stuck in a commitment that turns out to be unrealistic really sucks.

3) In my experience a good portion of orgs really are bad at business-engineering interactions and end up in adversarial relationships like you're talking about where engineering is seen as "those guys that refuse to commit to any deadline and suck at communicating status I can plan around" and the business owners are "those guys who don't understand what they're asking for and are constantly trying to micromanage to get blood from a stone". Also in my experience, neither side is entirely innocent in these situations.

> lose a customer because the feature they wanted is taking too long to finish

That's sales guy talking.

From my point of view, he is not a customer! A customer is someone who buys the product we currently have ready to sell, or someone who pays for customization.

1) Have you ever worked on the business side? And no, business =/= sales.

2) Except I have seen multiple times when customers paid for customization, then jumped ship (and demanded a refund) because that same customization took too long.

You shouldn't take money for what you can't deliver. If enough customers ask for a customization, add that to your pipeline and you'll have some good news to share when it's ready.

Customization for a customer is an area that needs extreme care. It's very easy to accept that "one little change" to get ink on that sales contract. And at times is a reasonable thing to do. But it can lead to a number of very bad situations. Scenario A, promise too many customizations at the same time you're going to have a bad time trying to deliver on them all. This is frustrating for everyone and is often the result of poor leadership. Pushing sales and revenue targets on one side while ignoring the very real resource constraints on the other. Scenario B, customizations that are customer specific, meaning a customization that isn't likely to be used by other customers due to a quirk in that single customer's workflow to get them to sign. This leads to feature bloat and increases the maintenance burden of the product over time.

There is a reason that product owners need to be able to say, "No" and be good at managing expectations. Otherwise they end up with an unmanageable backlog, broken promises, and sometimes will scapegoat the engineering team. That isn't too say over promising doesn't happen on the engineering side of the equation. But the product owner is the individual ultimately responsible for all feature work promised.

> push back multiple expensive dependent non-engineering projects

If those projects have to be pushed back, the only explanation is that they were started too early.

That's nice in theory only. In the real world, dependent projects often have long lead times, which often means foregone revenue for the business because of holdups.

> A lot of developers really hate committing to any kind of estimate

In development (as opposed to production) I personally fight against any commitment if it comprises the "what" as well as the "when".

You fix the date of the next release and provide me with a prioritized list of bug fixes and features to work on? Nice, let me start to work!

You think that a specific new feature could improve our sales and you let me drop anything else and call you back as soon as I have any news? Wonderful, I'm already analysing the issue in my head!

Anything else, and I'll let you know that your dreams are not likely to come true.

The iron triangle[1] is a well known model. If the "business" side insists on "engineering" breaking it, they are not serving their function.

[1]: https://en.wikipedia.org/wiki/Project_management_triangle

> how much work should we take

Why not ask that question instead of guestimating individual tasks ?

I think people loathe estimations because they are never the end point, only an input data to derive a result that people don’t want to let them decide directly.

It can be legitimate to not have your engineers decide of the roadmap, but you can’t fault them for feeling abused when you’re not asking the real questions.

That is the problem with sprints.

Why should you burn yourself out just to do an arbitrary number of tasks, based on wildly inaccurate estimates, just to meet an artificial sprint deadline?

To make the company more profitable at expense of your health.

The whole activity of estimation, planning and reviewing is often just a way to implement micromanagement.

What is the benefit? It pushes engineers to spend 100% of their time on urgent tasks and stop doing any learning, exploration of new ideas, discussing alternatives, socializing.

[Over]committing creates a constant sense of urgency that leads to higher productivity in the short term. Unsurprisingly, it's a source of burnout.

Reply on news.ycombinator.com