Hacker News Reader

Comment by shireboy | Hacker News Reader

I’d point out this isn’t a problem with estimation per se but with requirement gathering. The students didn’t press him for more specific requirements before offering an estimate. The real challenge though comes when the customer doesn’t know their requirements. They legitimately think they “just want a simple app to record urls”, but actually want all the other things listed. The thing that sets good developers apart is being able to tease out those requirements without being a jerk or making legitimately simple requests overly complicated, then deliver.

View on HN

Good developers, yes. Which takes experience, given the myriad of colorful personalities, politics and more. Though I don't think it is fair the responsibility is largely put on the developer for "underestimating" when often the corporate is big enough to have specific people gather these requirements and map them out as part of their day-to-day.

That's my main problem with this advice and the article. Of course anyone wants a developer who can do both development and figure people out to bring out the most perfect estimates possible. But it's getting to a point developers are starting to be the solely responsible people on top of ever increasing technical requirements, while being given the minimum amount of practice figuring all this stuff out.

My spouse is in healthcare, and at least in the US, it seems to be a similar situation.

There’s a big medical structure. And in theory, there’s lots of folks to deal with XYZ. In practice, docs need to do YZ because they are the ones who have the right combination of training and authorization to complete the task. When more people get hired, the doc just has to communicate YZ to more people. Either the task requires nuance that is missed if you’re not the doc, or the task requires direct doc authorization at various points regardless. Doesn’t decrease their burden at all, even though there’s more people working on YZ.

I think this is a great analogy.

Creating a game of telephone between the stakeholders and the people developing software is often going to impede communication.

The flip side of this is that a lot of technical people lack adequate soft skills to be able to do this requirements gathering well (probably the same can be said about a lot of doctors and what defines a "good" doctor).

Half the time the devs don't even underestimate, it's just that they're the easiest to blame them because it'll never hurt them (according to the people shifting the blame).

One time, I had to estimate a UI migration. I made the estimate and added the disclaimer that the estimation assumed X was true and Y and Z were provided. Of course, X wasn't true, because the supplier sucked and Y and Z weren't provided by the business. So it ended up taking way more time than estimated.

Guess who got the blame anyway.

It's even worse when you get pressured into giving unrealistic estimates, or even get overruled and have your estimate ignored, and then get blamed when the project runs over the estimated time.

If that ever happens to you, don't wait around and suffer. Start looking for another job and save your sanity.

You deliver with the minimum you can get away with then improve from actual feedbacks, requests and data gathered from usage.

What people think they will want differs from what people will actually want which is not necessarily what data shows you should build. Build fast, improve incrementally.

The path highlighted in the article is exactly how you should not build a product. Don’t focus on all the things you could add, streamline your ideas as much as you can.

You're right - I think this is the only real way out of the dilemma. There are still some challenges with this approach, though:

* stakeholders often need or think they need a whole estimate up front. A developer may explain MVPs, sprints, agile, etc. and still get blank stares and "ok, that sounds good, but just give us a rough estimate how long will it take/how much will it cost. We promise not to hold you to it (yeah right)". In some examples, like governmental budgeting, etc. it can be hard to even proceed through purchasing without a whole-product estimate.

* developers can be seen as over simplifying by stakeholders who don't understand the approach. When presented with a MVP, they start complaining about the fonts, etc. and loose faith in proceeding.

* developers can be seen as over complicating by stakeholders who don't understand the approach. When a stakeholder's simple request for "just an app to capture urls" balloons into a major project with bells and whistles over 10 weeks of dev cycles, management steps in and says "I thought this was just supposed to be a simple app to capture urls".

The later two come down to developers communicating effectively and stakeholders truly understanding their staff and processes. The first, I honestly haven't found a great fix for. No matter how I explain, many customers generally want an estimate and budget I stick to.

> The real challenge though comes when the customer doesn’t know their requirements

Which, of course, is true 80-90% of the time.

Fair but this is the thing we all do wrong with estimates. I've come to the following system that I think works well and captures the uncertainty.

Estimates are given as the following choices: hours, days, weeks, months, quarters. You never give a number tp the units. These all mean some "small number of X" where X is the list above. Then if Product has a question like, "Why would Z take weeks?" then you can have a discussion about the complexities and the task can be further refined and/or split into multiple things and those can be estimated as above, rinse and repeat.

Reply on news.ycombinator.com