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

41–50 of 231 posts

Re: Software estimation is hard – do it anyway

#41

Post by valenterry »

helsinkiandrew wrote: post #26
AndrewDucker wrote: post #12

Earlier quoted context omitted.

And when there are chunks that you haven't done before? Or when breaking it down will require going to a level of detail that means basically fully designing/writing your system in order to estimate it?

Yes! if you don't understand how something is going to be roughly designed/written then you're not estimating your guessing.

If you already know how to write it, why haven't you automated it? One could say, the worst developers are the best in estimating their tasks, because they repeat everything they do all the time. ;)

Re: Software estimation is hard – do it anyway

#43

Post by grey-area »

agentultra wrote: post #31

One major “secret” to advancing in a technical career is learning how to give accurate estimates. It certainly has been for me... Seems like there's a hint of survivorship bias. The author will eventually give a bad estimate. There's no secret or trick otherwise it would be widely known by now. Even the video games industry has been coming around on this in the last decade. This is a sector of the software industry f…

There are ways to control estimates - just have good controls on time, scope and cost and make sure every stakeholder is aware of and accountable for the impact of their actions in changing expectations.

Someone (sales team, developer or anyone else) wants to radically change the scope half way through? They have to cut the scope or adjust the schedule to compensate. Software is infinitely malleable so it's tempting to just accept any change that comes along, but with unmanaged changes and complexity come missed schedules and blown deadlines - it's all very predictable and avoidable and usually caused by a dysfunctional organisation without proper communication or accountability.

This is not rocket science and while there are no secrets or perfect estimates there are certainly ways to break down most work until estimation is trivial. Sure there are exceptions (research, v. difficult new problems) but for the majority of business/consumer software I've encountered, a proper schedule is possible and software can be delivered on time and on budget, as long as the scope is properly controlled, the work is properly subdivided early on and someone is managing the entire process and keeping communication open with stakeholders so that when things change/go wrong the appropriate action is taken and everyone is aware of why.

Re: Software estimation is hard – do it anyway

#44

Post by commandlinefan »

The problem with estimates is that you can only really estimate the best-case scenario - how long it seems like it would take if there were no surprises. If you base your estimate more on past experience ("I've never done this exactly, but I did something similar to this once before and it took a month"), the people demanding the estimates are going to push back and demand you itemize - mostly for the purposes of "negotiating down" your initial estimate. Which, of course, isn't an "estimate" in their mind, it's a rock-solid guarantee.

After 30 years in this profession, I've lost hope that we'll ever get away from the mindset that developing software is a mindless, mechanical, repetitive task rather than a creative endeavor.

Re: Software estimation is hard – do it anyway

#45

Post by SketchySeaBeast »

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)

That's the secret though, isn't it? The more likely you are to know all the steps the more likely you're going to make an accurate estimate. The catch there though is that if you know how you're going to do everything, you're already at least halfway through development.

Re: Software estimation is hard – do it anyway

#46

Post by ape4 »

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 .

You can give a range - eg 3 to 5 months.

Re: Software estimation is hard – do it anyway

#47

Post by nialo »

gtCameron wrote: post #35
throw-8462682 wrote: post #20

Earlier quoted context omitted.

Good estimates are critical to plan dependent activities and setting customer expectations. If we don’t estimate then we are saying that software engineering is not an engineering discipline. You can have that view, but in my experience it does not lead to good outcomes. If I can assume you’re an SDE for a moment, I actually agree with the part of you not providing estimates. Recently I’ve done the initial estimate f…

I don't think "real" engineering is necessarily any better at estimating. Take a look at any large construction project and the norm is to be over time and over budget. There are lots of reasons for that, which can fall outside of the scope of engineering, but the same is true for software.

I want to second this, I worked as a mechanical engineer and never had accurate time estimates there either. Estimates of how long the work will take will be wrong whenever there are new problems to be solved, which is all engineering worth the name.

Re: Software estimation is hard – do it anyway

#48

Post by ziggus »

Estimation that isn't based on previous data - I think the article that follows this one refers to it as "Evidence-Based Scheduling" - is almost entirely a waste of time.

We analyzed our five+ year history of estimates vs actual time, and our standard deviation was larger than our mean. It was ridiculous how wrong our estimates were. The problem was in what was being estimated - coding time. Developers would get asked how long a task would take, and only think about the time spent sitting in front of a computer, typing code, and not the other time - waiting for other resources or people to finish tasks that you depend on, sick days, software and hardware issues, etc.

The only way to accurately take those unforeseen factors into account is by analyzing previously completed tasks that have similar scope. Even then you can only get close.

A couple people have mentioned weather forecasting as a similar endeavor - but meteorologists don't just guess, they analyze previous data.

Estimation that isn't based on concrete data is a fool's game.

Re: Software estimation is hard – do it anyway

#49

Post by bigwavedave »

gortok wrote: post #21
sanguy wrote: post #19

To accurately estimate means developers and product management have collectively discussed the requirements to a level everyone understands clearly. Without this an estimate is as accurate as a weather report for 90 days out. A good estimate may also require "spiked" to test concepts to get to a reasonable estimate. I'm currently in a project that is terrible as the development team provides estimates without even re…

It’s just “a spike” or “spike”.

> It’s just “a spike” or “spike”.

I imagine the OP meant "spikes" and either accidentally hit the 'd' instead of the 's' or simply fell victim to autocorrupt.

Re: Software estimation is hard – do it anyway

#50

Post by agentultra »

grey-area wrote: post #43
agentultra wrote: post #31

One major “secret” to advancing in a technical career is learning how to give accurate estimates. It certainly has been for me... Seems like there's a hint of survivorship bias. The author will eventually give a bad estimate. There's no secret or trick otherwise it would be widely known by now. Even the video games industry has been coming around on this in the last decade. This is a sector of the software industry f…

There are ways to control estimates - just have good controls on time, scope and cost and make sure every stakeholder is aware of and accountable for the impact of their actions in changing expectations. Someone (sales team, developer or anyone else) wants to radically change the scope half way through? They have to cut the scope or adjust the schedule to compensate. Software is infinitely malleable so it's tempting…

Nothing about what you've said wasn't known and employed by people at companies who've made budgets and estimates that went over. This is why estimates and budgets go over. Everyone thinks they have it figured out.

The Taylorist principles of management don't apply to knowledge work in my experience. Refine your requirements gathering and estimation processes all you want. Your estimates will still be wrong most of the time. They're educated guesses and we don't have the foundation to make accurate ones.

One thing I think you nail though is that communication is key. A lot of good comes from being honest, transparent, forthcoming, and supportive.

I never recommend software teams and companies make estimates. I say break down tasks, make mile stones, set learning goals, and get to work. Communicate progress frequently and keep feedback coming back to the team. Working software talks. When you can see the goal in sight that's the time to start talking about release dates. Once you have that first couple of releases you then you can start developing a cadence. It's all based on evidence and what you know and making promises you can keep.

Post reply on HN