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

191–200 of 239 posts

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

#191

Post by mkempe »

fjsolwmv wrote: post #179
mkempe wrote: post #60

Earlier quoted context omitted.

In the context of a fixed-time, fixed-price/budget project it will fail to meet these constraints unless the scope is very clearly delineated at the outset, and ruthless scope/change management is applied throughout the progress of the project. And if at some point someone realizes that there was an omission in the scope definition, the time and budget must change. If the client or management want to change the scope…

Well sure, if you doom the project before you start, with a fixed price and scope, it will fail. The original primary point of the Agile Manifesto is to stop doing that. There's no excuse for it, unless you are required by law as a government contractor, and in thar case no one expects a successful result anyway.

I've seen and worked on many successful fixed-time, fixed-price projects, medium- and large-scale, not for government.

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

#192

Post by jrs235 »

chiefalchemist wrote: post #105
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…

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.

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

#193

Post by nickthemagicman »

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…

It's like building a deck except even the screw hasn't been invented yet. And you think: I'll just create a device that attaches the wood like a big paperclip but then realize after you make it that it's not strong enough and won't scale so you create a nail. But then you realize you may need to reuse the wood so you finally create a screw.that can be removed.

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

#194

Post by jacques_chester »

ghettoimp wrote: post #177
wvenable wrote: post #140

Earlier quoted context omitted.

Estimates in software are effectively experienced guesses. This is in contrast to other industries, such as construction, where planning is done for months to ensure the estimate of time and materials is accurate. If you attempt to treat one as the other, you run into huge problems. Software isn't like building a bridge; it's like planning to build the bridge. I'm pretty good at software estimating; I can roughly tel…

Heh. But even in construction projects, serious cost/time overruns are very common. I can't find a good source through quick googling, but what I do find is horrifying.

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

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

#195

Post by mannykannot »

nickthemagicman wrote: post #193
mannykannot wrote: post #167

Earlier quoted context omitted.

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…

It's like building a deck except even the screw hasn't been invented yet. And you think: I'll just create a device that attaches the wood like a big paperclip but then realize after you make it that it's not strong enough and won't scale so you create a nail. But then you realize you may need to reuse the wood so you finally create a screw.that can be removed.

That analogy might have worked in the 1950s.

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

#196

Post by jacques_chester »

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.

"Will management abuse the estimation process?" is a different question from "is estimation possible and improvable?"

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

#197

Post by jacques_chester »

AstralStorm wrote: post #188
softawre wrote: post #142

Earlier quoted context omitted.

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

Sometimes there are no "small chunks" and this is where all agile approaches fail. If a thing does not work it is not a deliverable. Bonus points if the thing is not really testable because it is tied to platform/OS. (And you'd either have to implement it in full our spend weeks implementing a test harness.)

> Sometimes there are no "small chunks" and this is where all agile approaches fail.

I work at Pivotal. Cloud Foundry is a successful application of agile (XP + Lean trimmings) to a large, complex distributed system.

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

#198

Post by jrs235 »

fokinsean wrote: post #157
mirceal wrote: post #27

Earlier quoted context omitted.

Have you ever been in a situation where communicating and breaking things down takes longer than the actual work? IMHO most disasters I’ve seen occur when ‘Product’ tries to strictly control the ‘Developers’. It just does not work for certain kinds of projects. It also diminishes the developers’ involvment and leads to a culture of mediocrity and CYAs. Also, a person that does not have to do the work will always be w…

> Product trusts Dev on implementation Currently having issues with this one right now, and it is the most frustrating thing I've experienced at a job.

Ditto. A colleague called into question an off the top of my head estimate. A 2 day estimate and tried squeezing me to cut it down more... For work I wouldn't even be doing. Nope. Not going to do it. I tried to call into question his estimate of how long it would take for one of his sales guys to sell the lead he received yesterday. Once he threw out a number I asked why so long? Needless to say the conversation didn't end on a good note. Live and learn. We'll talk it out tomorrow. A quick way to lose trust and respect is implying incompetency and squeezing/trying to manipulate people. Really kinda pissed at him right now.

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

#199

Post by ghettoimp »

jacques_chester wrote: post #194
ghettoimp wrote: post #177

Earlier quoted context omitted.

Heh. But even in construction projects, serious cost/time overruns are very common. I can't find a good source through quick googling, but what I do find is horrifying.

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!
Post reply on HN