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

Why Development Teams Struggle to Deliver on Time, on Budget, or at All

7pace.com

Post reply on HN
Print view View original

141–150 of 239 posts

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#141

Post by nradov »

diego_moita wrote: post #84
Aaargh20318 wrote: post #43

The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work). To use the 'going to the supermarket for milk' example. I could make a fairly accurate estimate for that because I've gone to the supermarket hundreds of…

A lot of people have been praising this "estimates based on data and rigorous planning" for decades. Steve McConnell wrote a whole book about it (Software Estimation: Demystifying the Black Art). It works only very special circumstances: when the task can be very well defined because it has been done a lot of times before and the people doing the task are very experienced on it. But the caveat is that if you are doin…

If you actually read Steve McConnell's book the focus is really on accurate estimates more than data and rigorous planning. He makes it clear that a high level of precision is impossible in some cases. (Many people fail to appreciate the difference between accuracy and precision.)

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#142

Post by softawre »

harryf wrote: post #112
snowwolf wrote: post #73

So the author of this has a vested interest in their "solution" being the correct one, but I fundamentally disagree with it. I agree with their hypothesis that we are bad at planning/estimating, but the solution is not spending more time on it, but rather less. Firstly I really like this humorous look at the problem: https://www.quora.com/Why-are-software-development-task-esti... You cannot estimate what you don't kn…

> You cannot estimate what you don't know Exactly! It tried to express that and a strategy for handling unknowns here - https://medium.com/@hfuecks/what-donald-rumsfeld-can-teach-u... My theory is the reason why we’re not getting any better at estimating software projects rests on a flawed assumption; because computers are binary and deterministic, we assume that the process of creating software must also be determin…

Agile has a concept called the cone of uncertainty.

The way we use this concept in practice is by doing small chunks and delivering fast, and the more chunks we have done with a project/feature/whatever the more likely our estimates get better over time because there is less work left and we are more familiar with the work now.

http://www.agilenutshell.com/cone_of_uncertainty

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#144

Post by nradov »

Aaargh20318 wrote: post #102
jungturk wrote: post #81

Earlier quoted context omitted.

> Development time estimation, and every methodology that attempts it (I'm looking at you, Scrum), are little more than desperate attempts by managers to feel in control and relevant. More charitably, they're an opportunity to introduce system 2 slow thinking on the team. There are certainly novel engineering problems that simply won't yield to estimation, but there are also lots of well-solved problems that will. Ma…

> there are also lots of well-solved problems that will But if it's a solved problem, why not use the existing solution ?

Even if the solution exists you still have to integrate and test it. Those tasks can require a lot of engineering labor, but fortunately they're fairly amenable to estimation.

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#145

Post by hinkley »

kareemm wrote: post #7

In my experience talking to hundreds of software engineering managers, running a software project management business, and being involved on software dev teams for 20+ years, there are two reasons why teams don’t ship or ship poor software. 1. Poor engineering planning. The way to do this well is to break down a feature until they’re at about half-day sizes tasks. Identify any obvious risks or ambiguities with the te…

With the exception of video games, I maintain that it's always better to be 10% over estimate on every milestone than to all of a sudden be 50% off of the final deadline.

To work it takes being comfortable saying "that's my/our fault", and my experience is that a lot of people who would rather die than admit fault. It's part of a larger raft of skills around transparency. So they cover up problems hoping for some miracle that never comes (or more cynically, they hope to be employed somewhere else before the shit hits the fan).

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#146

Post by nradov »

wildekek wrote: post #35

Higher up manager here. I fully accepted the #noestimates movement and it is a complete blessing for all the teams and organizations I've implemented it in. Roast me.

How do you prioritize which features to work on? If you have to pick between two features with similar expected value (or similar cost of delay) then you need at least rough relative estimates to make a rational decision.

https://www.scaledagileframework.com/wsjf/

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#147

Post by [deleted] »

jbigelow76 wrote: post #98
Aaargh20318 wrote: post #43

The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work). To use the 'going to the supermarket for milk' example. I could make a fairly accurate estimate for that because I've gone to the supermarket hundreds of…

The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work). If you can plan and execute putting a person on the moon, you can plan and execute software development. I think the problem is the overwhelming majority…

[deleted]

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#148

Post by eitland »

jbigelow76 wrote: post #98
Aaargh20318 wrote: post #43

The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work). To use the 'going to the supermarket for milk' example. I could make a fairly accurate estimate for that because I've gone to the supermarket hundreds of…

The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work). If you can plan and execute putting a person on the moon, you can plan and execute software development. I think the problem is the overwhelming majority…

Getting to the moon took many many man years of planning, experiments, material development and cost a few lives. It also involved several of the worlds leading scientists, and probably the best computers money could get at the time.

If you can accept those kinds of preparations and also agree to not change the specs much (i.e. no, we aren't going to Mars instead) after we've started developing it I'll say we can get you a pretty nice estimate.

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#149

Post by raphaelb »

nradov wrote: post #141
diego_moita wrote: post #84

Earlier quoted context omitted.

A lot of people have been praising this "estimates based on data and rigorous planning" for decades. Steve McConnell wrote a whole book about it (Software Estimation: Demystifying the Black Art). It works only very special circumstances: when the task can be very well defined because it has been done a lot of times before and the people doing the task are very experienced on it. But the caveat is that if you are doin…

If you actually read Steve McConnell's book the focus is really on accurate estimates more than data and rigorous planning. He makes it clear that a high level of precision is impossible in some cases. (Many people fail to appreciate the difference between accuracy and precision.)

I haven't read the book and was going to ask about accurate vs precise but found this helpful article discussing it as it relates to software here if anyone else is curious about that distinction: http://itsadeliverything.com/accuracy-vs-precision-in-estima...

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#150

Post by nradov »

Jtsummers wrote: post #97

Software is design, not construction. This is why it's hard to estimate. You ask an architect to design a new skyscraper in a fixed three-month timeframe, good luck. It won't be what you want, or it'll have severe problems discovered during construction. Software developers are creative workers, we have to accept this. Unless you're doing the nth iteration of basic CRUD/RESTful web app, or a trivial "display data fro…

Architects regularly design new skyscrapers on fixed schedules. Look at some of the major developments going up in China.
Post reply on HN