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

191–200 of 231 posts

Re: Software estimation is hard – do it anyway

#191

Post by regularfry »

ppeetteerr wrote: post #151
rantwasp wrote: post #128

Earlier quoted context omitted.

here is the problem: estimating is also work. breaking down the work is hard work. sometimes it takes more to break down and think things through than to do the work. the fundamental problem is that management does not want estimates. they want quick estimates (ie close to zero effort) and after that they turn around and use those estimates as deadlines. now as a developer what are you supposed to do? you’re gonna ge…

As a manager and I can tell you that the push back to estimates is primarily from engineers and cheap company owners ("why spend time estimating when I/they can code?"). Estimating, wire framing, documenting, manual testing, security testing, etc are all hard but necessary. If you don't schedule time to estimate, the estimates are worthless. Rule of thumb, anything that can be done by one engineer in less than 1 mont…

Well, yes. Estimation is design. Only if you call it "estimation" the engineer who's been berated into crunch-overtime for a miss in the past won't want to do it and will do it badly when forced, and the cheap company owner whose own behaviours drive teams to estimate badly ("that estimate's huge, I'm not paying that, estimate it again but smaller") won't have had good experiences to understand why that design phase is valuable.

There needs to be enough time in the schedule to design to an adequate level for the problem at hand. You don't necessarily want as clear a picture as possible, but you do want as clear a picture as necessary.

Re: Software estimation is hard – do it anyway

#192

Post by regularfry »

tutuca wrote: post #129
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…

Agile, is in practice, a way to have the dev team under more strict scrutiny than anyone else in the org. It doesn't happen anywhere else, mostly because other industries have a long standing unions and working rights instead of free "professionals" doing services.

Which is ironic, because one of the driving design decisions in both XP and Scrum was to provide protection for the dev team from overbearing project management.

Re: Software estimation is hard – do it anyway

#193

Post by User23 »

city41 wrote: post #85
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…

Asking for estimates is fundamentally an expression of distrust. It’s obviously unpleasant to have to participate in a regular ritual in which those in power over you express their distrust.

Don’t get me wrong, sometimes distrust or limited trust is justified, but it’s not an ideal.

Re: Software estimation is hard – do it anyway

#194

Post by pyrale »

kyriakos wrote: post #163
ItsMonkk wrote: post #80

Earlier quoted context omitted.

> customer expectations My favorite moments from events like WWDC are when you are introduced to some really cool feature or app for the first time, and then the speaker goes "available today". The fans love it, the news sites love it, whenever you can immediately try out something the hype for that product goes up 10x. When you only show the product when it's finished, you no longer need to estimate anything. > depe…

Regarding the WWDC comment, of course an estimate was needed in the first place cause WWDC day was also the projects deadline.

Here is the secret: If it misses the deadline, it's going to be announced at the next event.

Re: Software estimation is hard – do it anyway

#195

Post by shakezula »

I absolutely loathe software estimates. They put engineers in a damned if you do, damned if you don't scenario that isn't even in their full control anyway.

I think this is one of the things that Shape Up got the most absolutely correct - inverting the relationship between an estimate and time.

We've been asking the wrong question all along: Instead of asking "how long will X take?" you should be asking "How long do I want to spend on X?". It changes the entire dynamic of the situation to one that allows management to see the trade-offs in a given set of work, and lets the engineers tune scope to match expectations.

Any approach that still asks "How long will X take?" is dead in the water.

Re: Software estimation is hard – do it anyway

#196

Post by pyrale »

wtetzner wrote: post #78
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…

> Good estimates are critical to plan dependent activities and setting customer expectations. One of the things I dislike when I hear this is that it says nothing about the difficulty or cost of getting the estimates. Yes, good estimates are extremely valuable, but solving the halting problem would also be very valuable. That doesn't mean it's going to happen. A big issue is that to get good estimates, often we need…

> but solving the halting problem would also be very valuable.

The halting problem is mostly a non-problem in settings that really need a proof. We have non-turing-complete languages that let us produce programs that provably halt.

That they are not mainstream tends to show that we don't really need that proof very often actually.

Re: Software estimation is hard – do it anyway

#197

Post by pyrale »

0xcoffee wrote: post #22
tut-urut-utut wrote: post #9

Don't do it if you can avoid, especially if company culture is to treat rough estimation as a promised deadline. If you can't avoid giving estimation, try to pad it as much as possible, add every single uncertainty to the task list, and estimate very conservative. Add enough time for testing, communication, work on change requests. And even after the original estimate is approved / published be sure to communicate up…

I find estimations a useful process (on user story level). Sometimes team members will have wildly different estimations, and then there is discussion why, and often new information is learned. I know this is basic agile stuff, but I find in practice it works well.

The discussion can be had independently of the estimation.

Re: Software estimation is hard – do it anyway

#199

Post by hyperpallium2 »

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…

It's also very useful for personal projects, where you are the entire stack. Strangely, it's still difficult to get that buy in...

Re: Software estimation is hard – do it anyway

#200

Post by astockwell »

Animats wrote: post #150

Paid overtime will fix scheduling. Scheduling is bad because the cost falls on the employees, not the employer. If crunches resulted in time and a half, double time, and triple time, scheduling would get fixed. As I've pointed out before, film scheduling is an established discipline. Making a movie is much more complex than a software project. There are a lot of moving parts. Things get changed. There are people prob…

This is the truth. Change doesn't happen until the decision-makers feel the pain of their decisions.
Post reply on HN