Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software estimation is hard – do it anyway

jacobian.org

Post reply on HN
Print view View original

81–90 of 231 posts

Re: Software estimation is hard – do it anyway

#81

Post by _y5hn »

It's funny. I found only one post that reflected agility in their process as per AM. Yet, "Agile" is recognized as industry standard, while the required maturity is lacking, in both devs and product side. Achieving that level of coherency is fiercely hard, or you're just lucky the circumstances allow it.

In some scenarios you need projects and full-on estimates though, ie. for planning of hard deadlines. But the reason you want to avoid it has to do with the discovery process during development. Everyone conventiently "forgets" this while focusing on their own ends (local optimization).

Quick feedback-loop with A/B tests are maybe easiest way to achieve understanding on how AM recommends people develop together. Such setups may end up costing alot though, unless truly done in the spirit of AM and recognizing the costs of shortcuts.

Re: Software estimation is hard – do it anyway

#82

Post by mr-wendel »

steverb wrote: post #23

Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. The process will require dev resources, business resources and probably people from the support team and will take a lot of time. I'm happy to do it. It's a…

What a fine cut of beef this was! The very last sentence is what really gets me:

  > It requires buy in and input from the entire business stack.
In my experience, this makes or breaks everything. Unless you have external buy-in and external understanding of all the points steverb enumerated:

  - Inaccurate estimates don't matter: there is so much wack-a-mole going on that by the time you're done it just doesn't matter as everyone is 3+ focus hijacks removed from when you started.

  - Accurate estimates cause heartburn: they wanted it weeks ago and now you're showing up with a number far larger than anyone wants to hear, but they can't tell you where to cut scope.
Additionally, the point of estimates is planning, and planning really only matters when it aligns priorities for multiple teams... the more alignment needed the more important this becomes.

Everyone has to do the dance or it's just no fun.

Re: Software estimation is hard – do it anyway

#83

Post by Buttons840 »

A problem is that people have different things in mind when they ask for estimates.

For some, an accurate estimate would mean that 50% of the time you're over and 50% of the time you're under. But management too often takes this type of 50/50 estimate and then makes all kinds of promises and contracts based on it. If you want an estimate that we're going to hit 99% of the time, that is going to be much much higher. Many places I've worked management would balk at any discussion of percentages like this when making estimates.

As the saying goes: What you say is "there's a 50% chance we'll be done in 6 months, if there's no distractions". What they hear is "I promise we'll be done in 6 months".

Re: Software estimation is hard – do it anyway

#84

Post by wtetzner »

trentnix wrote: post #67

If you want the business to set effective priorities, you've got to provide estimates. You can't figure out cost-benefit without some idea of cost.

Seems like giving time-based estimates just isn't feasible, though. Sure, for some types of problems it's not hard (though it feels like tasks that can be that easily estimated should probably be automated), but many are new/hard problems that need to be solved. Yes, it would be great to have accurate time-based estimates, I don't think anyone disagrees with that. But there are lots of things that would be great that we can't have.

Maybe just ranking tasks by difficulty, or using Fibonacci rankings as recommended by some for Agile story points, would be a better use of everyone's time. That way, you can still say "A is roughly X times harder than B", without trying to rely on (almost certainly wrong) estimates in terms of days/months/years.

Re: Software estimation is hard – do it anyway

#85

Post by city41 »

notional wrote: post #53

I work at a place now that ditched the time estimates and the sprint planning meetings and standups that go along with that and it's so much better. Time estimates are always wrong, it always slips to the right. This is always used against you. You suffer because of it. Your work suffers because of this. I get a couple extra hours a week by not doing daily standups, retrospectives, sprint planning, etc etc. This allo…

At my last company I worked on two very different sides of it throughout my time there. One side did no estimates at all as the nature of the work could afford that. The other side heavily relied on estimates and spent a lot of time planning and creating them. I found the non-estimate side of the company vastly more sane, enjoyable, less stressful, etc.

I get why stakeholders want estimates, don't get me wrong. But I can't help but think just letting them go and trusting the team is ultimately more effective in many cases.

Re: Software estimation is hard – do it anyway

#87

Post by rorykoehler »

pylua wrote: post #8

A big problem is that estimates given by developers are never treated as estimates but rather as quotes . If you miss your estimate then your employer may expect you to work extra hours to make up for the gap . Best strategy is to under promise over deliver .

Nothing would get built if 100% accurate estimates were given. Finance would say it's too expensive and that would be that.

Re: Software estimation is hard – do it anyway

#88

Post by Buttons840 »

helsinkiandrew wrote: post #7

Software estimation is only hard when you don't understand what you have to do or how it will be done. Just keep breaking the problem down into sub units that you or your team understand and can fairly accurately understand the effort and risk of (because they've been done before)

It's going to take awhile to break all this down, management wants an estimate of how long these estimates will take. :\

Re: Software estimation is hard – do it anyway

#89

Post by codeptualize »

I prefer to not give exact estimates whenever possible as the unknowns will ruin your estimate anyway.

If necessary I prefer to get very clear what is needed to [make that sale/give that demo/whatever they need] and give a very conservative range with a bunch of caveats. The more flexible the requirements and timeline the better. It means with a bit of luck you can deliver early and/or throw in some bonus stuff at the end.

If you are inevitably going to miss a deadline, discuss it as early as possible and discuss how to proceed, where to focus etc. You can often reduce the scope, cut more corners, move the deadline, find more resources, or do damage control. Whatever is necessary.

That's why I don't think (accurate) estimates matter too much, it's more about communication, managing expectations, and being flexible enough to adapt along the way.

Re: Software estimation is hard – do it anyway

#90

Post by mason55 »

steverb wrote: post #23

Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. The process will require dev resources, business resources and probably people from the support team and will take a lot of time. I'm happy to do it. It's a…

> Good and accurate estimation is not just a dev function. It requires buy in and input from the entire business stack.

And in my experience, when people don't want to buy in to doing the whole process up front but they still demand some kind of commitment, the easy way to handle it is:

"We can commit to a date and we'll finish whatever we finish by then, or we can commit to a scope and it will take as long as it takes. But we won't commit to a date and a scope unless we spend the up front time to first figure out every detail of what we need to build."

Stating it like that usually makes people realize how ridiculous it is to commit to something, but you don't know what, but you'll still do it by a certain date. And it makes them feel like you're being willing to work with them/gives them some decision making power.

Post reply on HN