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

91–100 of 231 posts

Re: Software estimation is hard – do it anyway

#91

Post by brightball »

tomrod wrote: post #69
brightball wrote: post #51

Earlier quoted context omitted.

This is 100% accurate and it's the reason that I prefer the SAFe (Scaled Agile) approach to estimation and planning over the common Scrum approaches. Doing the bulk of your planning during a 2-3 day PI Planning event lets a lot of people dive into a few things, preparing an estimate for the coming quarter, mapping dependencies across teams, lining them up with other planned work and outlining risks to the plan. Then…

In practice, devs are still writing code on PI days.

How so?

Re: Software estimation is hard – do it anyway

#92

Post by majormajor »

username90 wrote: post #60
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…

> 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. This is almost surely wrong for most developers, or else rewrites wouldn't fail to deliver within the estimated time so often. Rewrites per definition already has a perfect specificatio…

> This is almost surely wrong for most developers, or else rewrites wouldn't fail to deliver within the estimated time so often. Rewrites per definition already has a perfect specification in the old code, just write something working the same way using a new architecture. But that is still really hard to deliver apparently.

This is precisely why rewrites fail!

I've never seen a rewrite where the devs had a perfect understanding of what the old code was doing. They understand the happy path, probably. Not the millions of edge cases through the years.

They only learn the requirements after knocking out the easy stuff and then getting into the gritty bits of bringing over all the edge cases that didn't fit their new mental model easily.

Re: Software estimation is hard – do it anyway

#93

Post by tiagogm »

ziggus wrote: post #48

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 aske…

Kanban lends itself well to this.

Breaking down work into similarly sized tickets/units can, over time, be used to predict delivery/capacity (which one can use Cycle time to calibrate)

Even neater with enough data it becomes possible to use Monte Carlo simulations to give you confidence intervals on how much can you do or how long you will take to do X amount of work.

https://kanbanize.com/kanban-resources/kanban-analytics/mont...

I find this approach a lot less time consuming, more predicable and reliable.

Re: Software estimation is hard – do it anyway

#94

Post by grey-area »

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

Earlier quoted context omitted.

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 t…

The Taylorist principles of management don't apply to knowledge work in my experience.

The simple principles above do apply in my experience, presumably there is some difference in practice.

Maybe everyone thinks they have it figured out but some people demonstrably do, because they deliver software on time which meets requirements. I agree with delivering software early and often, and that is a solid basis for delivering reliable estimates and promises you can keep.

Where estimates fail IME it's down to lack of accountability and communication among stakeholders, which leads to constantly shifting and unclear priorities and requirements.

Re: Software estimation is hard – do it anyway

#96

Post by rorykoehler »

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…

For most saas out there, once all the requirements are that well understood the product is already 70% built.

Re: Software estimation is hard – do it anyway

#97

Post by handrous »

citizenpaul wrote: post #62

I used to do real estimates and was borderline prophetical on them. Didn't matter. I stopped and now just do a rule of thumb plus two weeks, two months, two years depending on the project. Professionally it changed nothing. For me it made my life much better and now projects come in "early" and make customers happy. Instead of people frothing at the mouth because it was a "day late" Why do we as an industry put up wi…

> Why do we as an industry put up with this? Lawyers Don't, Doctors Don't.

It's a class difference. Fussell places the typical doctor or lawyer in the Upper Middle. Most developers are, in their relationships with their employers and their employment (not in terms of income!), Mid-Prole, High-Prole, or solidly Middle, under a Fussellian classification. Elevating us to Upper-Middle would put us on par with much of upper management, and where most middle managers want to be but are not and are constantly irritated that they are not, in terms of freedom and respect.

No surprise that corporations (managers, in particular) resist this inversion of class-liberty compared with the corporate hierarchy, especially since they (managers) set the rules and the tone. It's bad enough we might make more money than they do. And besides, most developers haven't been socialized, in childhood, in school, or in their early career (so, the periods of life when class education occurs) into the Upper-Middle. We don't really expect better, would probably feel uncomfortable or like beggars requesting better, and (truly) may even feel uncomfortable or lost with the resulting freedom.

Put another way: who do doctors in a hospital answer to? Who do lawyers answer to, in a law firm? Classically, doctors and lawyers, right? Notice how upset doctors are about professional management infiltrating hospitals? That's them resisting dropping down in social class.

Re: Software estimation is hard – do it anyway

#98

Post by lowercased »

mason55 wrote: post #90
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 tak…

> commit to something, but you don't know what...

The problem comes in when people think they do know 'what' it is, and they're just... adamant that you 'computer people' don't 'get it'.

I can't speak to all my clients - some are great - but have had some in the past that just insisted I was being obstinate or obtuse or difficult by asking clarifying questions. Then they'll take hours/days obsessing over shades of blue for a screen, then... the morning of 'feature launch' they'll question why there are no notification emails for feature X, when... that morning is the first time those words have ever been spoken.

But... fortunately, I've not had project work like that in a while :)

Re: Software estimation is hard – do it anyway

#99

Post by handrous »

xedrac wrote: post #70
Tade0 wrote: post #55

I stopped playing such games and currently do something else: I shave the scope as much as possible and make sure to report on my progress daily - usually by demoing. This is actually something that was originally suggested by my manager in one of my former projects. With the scope devoid of non-critical pieces and daily updates it's easier to monitor the progress and notice any roadblocks early on. Normally you'd do…

Demoing every day only works if your work is easily visible, but that's beside the point. Micromanagement to this level is not conducive to a healthy development environment.

> Demoing every day only works if your work is easily visible

I don't much like front-end work, but seeing how easy it is for front-end devs, designers, and UX folks to get noticed, makes me seriously reconsider my priorities, sometimes. For them, it's practically effortless, just something that happens.

Post reply on HN