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

201–210 of 239 posts

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

#201

Post by cmroanirgo »

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…

To keep with the 'going to the shops to buy milk' theme you can break it down into bits you can estimate. Assuming you've never bought milk before:

- how long will research take? Where do you buy milk? Where is the nearest shop? 3 mins.

- how long to get to nearest shop and back (eg 10mins x 2) = 20 mins.

- find milk in shop (30 secs to 5 minutes), so say 4 mins.

- Buy milk. (1 to 5) say 3 mins.

Don't forget that these are estimates and always add a bit of headroom. The above comes to 31 mins, so say 35 and you know you're covered. If the manager isn't happy with it, give him the low down figures.

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

#202

Post by redler »

DanHulton wrote: post #64
ttul wrote: post #11

Earlier quoted context omitted.

Having worked in the trenches as a software engineer and also as a CEO has given me respect for the VP level as well as the engineers. When the VP sets a deadline, it’s driven by the survival of the company - aka release by June or we can’t make our numbers and have to do layoffs. When the engineers push back, they often do so without an appreciation of the business reality, aka those numbers pay their salaries. Engi…

Ideally, yes, a deadline is set for a specific business reason. But I cannot count the number of times a deadline has been set for a project that is just utterly arbitrary, proven by the project releasing successfully on the deadline and then being immediately abandoned and forgotten about. Feature launches without marketing, website redesigns without fanfare, architecture refactoring that sits on the shelf for a mon…

“Our developers need deadlines. If I don’t give them a deadline, the work will never get done.” — Many, Many Managers

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

#203

Post by davewasthere »

Utterly awful article.

If I know that I've gone and gotten the milk a dozen times or more recently, I have a pretty good idea of the minimum and maximum amount of time it'll take me to go get that milk. It's 4km, about a seven minute drive, and the quickest I've done it is 20 minutes round trip, and the longest about 40 minutes (probably browsed the store a bit for other stuff), then I can give a fairly confident range quite quickly without having to over-plan.

It's after you've gotten the milk that the client remembers they're lactose intolerant and can you please go get some almond milk. That's when you get over-time over-budget. Although in hindsight, perhaps I should have asked what sort of milk they prefer.

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

#204

Post by khyryk »

mohaine wrote: post #55
fvdessen wrote: post #25

Earlier quoted context omitted.

> The way to do this well is to break down a feature until they’re at about half-day sizes tasks. I have never seen that work in practice.

Breaking a task down into meaningful half day task is almost as hard is just implementing it, but usually this is attempted in a committee setting. This is not a recipe for success.

Agreed. Think of how ridiculous it would be to make a half-day task for figuring out X -- sometimes I've spent days, even weeks, trying to figure out how a module works.

In practice, being able to break things down meaningfully and accurately to such a minute level implies that a lot of time was spent in grooming, which means we're just back to waterfall again. (Or the tasks at hand really are just that simple and/or the people involved have a lot of expertise.)

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

#205

Post by aaron_m04 »

philliphaydon wrote: post #133
avip wrote: post #113

Earlier quoted context omitted.

Yet if I ask you how long it takes to buy icecream in Japan, based on your experience grabbing milk in the US, your guess will be "less than half a day". Which is good enough for me.

And when he returns with the ice cream I’ll tell you I wanted Hokkaido ice cream.

And "quick question: what's the level of effort for making it tempura ice cream?"

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

#206

Post by jacques_chester »

ghettoimp wrote: post #199
jacques_chester wrote: post #194

Earlier quoted context omitted.

Industrial Megaprojects by Edward W. Merrow essentially shows that we're comparing ourselves to a myth of our own invention.

Thanks, wow, this looks like a really interesting read!

It is actually quite fascinating to see how our cousins get on. He's quite blunt about the dynamics that cause failure and that relatively few megaprojects ever live up to their business case.

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

#208

Post by chrisbennet »

mannykannot wrote: post #167
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…

This claim of inescapable novelty has a kernel of truth, but it is being exaggerated beyond any sense of proportion. If everything you have done in your day-to-day work has been beyond-estimating original, then either you could out-Knuth Knuth (in which case, kudos to you, and I hope you will have time to write the books someday, but your experience is not generally applicable), or you have been goofing off some of t…

You aren’t wrong - for some things. I think it’s a spectrum.

For the things I work on, and frankly always have, I spend most of my time in the “R” part of R&D. Now granted, I’ve never worked on classical “business” or CRUD type problems.

It’s natural to think that once you have lots of experience, that estimating will be easier. In my experience, I found myself simply tackling harder or unique problems. Instead of getting comfortable, you find yourself mostly operating at the edge of your competence. This is great fun [1] but makes estimating pretty hard.

[1] I personally enjoy being on the “black diamond” part of the learning curve. (“Black diamond” = most difficult ski trail)

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

#209

Post by cabalspecter »

notheguyouthink wrote: post #123
Aaargh20318 wrote: post #99

Earlier quoted context omitted.

> I think what's missing here is that I can predict how long something is going to take when I talk with the managers/feature-planners about what the feature is. If I feel I have a solid understanding of the requirements, which pieces of code it'll touch, etc - then I can give a reasonable estimate. I'd argue you can't. Right now I'm working on a feature that I estimated as 'a couple of hours'. I've been working on i…

> Right now I'm working on a feature that I estimated as 'a couple of hours'. I've been working on it all day by now. Not because the feature is that difficult, or because I didn't get a set of good requirements. The requirements are crystal clear and should be easy to implement. Just because you're wrong sometimes doesn't mean you can't be right more often than not. Another way to look at it is, as a company how can…

This is for me the dissonance between agile methodologies and reality. Agile methodologies assume having a flexible scope and time due to the project unknowns (technical, business, social, etc.). But usually budgeting in the real world is required to follow: I promise to deliver X scope that’s going to cost Y dollars in Z time.

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

#210

Post by chrisbennet »

jrs235 wrote: post #192
chiefalchemist wrote: post #105

Earlier quoted context omitted.

Oh. I feel your pain. But to clarify: You can't predict things well that you haven't done before. The point being, when trying to predict an unknown it's best to give a range and not a fixed estimate. If possible.

And then management only hears the low number of the range.

I like to use the range: “2 weeks to 2 years - roughly.”
Post reply on HN