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

121–130 of 239 posts

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

#121

Post by mirceal »

lostcolony wrote: post #115
mirceal wrote: post #76

Earlier quoted context omitted.

Maybe, maybe not. I’m very suspicious of things that are pitched as a panacea for everything. The real world is a messy place where even with a good team, a good plan and sensible expectations you can fail spectacularly. If there is one thing that I really like is aggressive validation of the assumptions that are being made + keeping the product as small and lean as humanly possible (and the latter should apply acros…

Oh, I'm not saying it's a panacea for everything. Just that most issues I've seen along these lines were also accompanied with a perspective on the business side that their role was to give solutions, which were invariably insufficient, led to the dev team just doing the minimum (since they had no idea what the core problem was and thus were unable to determine where 'sufficient' really was), and that compounded.

That definitely happens and it’s... unfortunate

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

#122

Post by san_at_weblegit »

The fact that there are so many reasons for the failure itself tell why the failures are so frequent. I strongly believe that it should be more than just the development teams which should be attributed for failures. Projects rarely get delayed or fail cause of developers only, the more responsible parties are management and the company culture. Even the strongest of the developers would learn over period of time that sticking to a more realistic schedule would not earn them praises. Unfortunately the path to promotion is to keep the bosses happy in most places. Most people do not have motivation about the end results, its more about looking good on day to day basis. Keeping the failures aside what has worked for me in the past is to add little padding (10%-20%) to all the tasks which no one would question and then we have enough padding to cover for any task in which the team really spent around 1000% percent more time than estimated. Again it really depends on how much the product people understand the efforts involved in development. Its hard to make some one believe that one line change took 3-4 days and another 1000 lines were added in half a day if they have not been there themselves.

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

#123

Post by notheguyouthink »

Aaargh20318 wrote: post #99
notheguyouthink wrote: post #88

Earlier quoted context omitted.

This is being a little extremist, no? I'm consistently asked to give estimates, and I mostly give estimates that are accurate within sane expectations. 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 c…

> 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 you budget anything if you can't make even the slightest of estimations?

What you're suggesting results in throwing away any ability to budget, roadmap, coordinate, etcetc. Absolute prediction is of course impossible, but if what you're saying is true than I should buy a lottery ticket because my estimations are insanely lucky.

And sure, I get estimations that run long, we all do - I'm not saying otherwise.

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

#124

Post by superjan »

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…

Very well put. It reminds me of the “Halting Problem”. Although for a subset of programs, it can be proven that they will finish in a predictable amount of time. Maybe this also holds for projects.

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

#125

Post by smdz »

The simple fact is that individuals or companies following System 1 have a much greater chance of survival in the competition. The consulting individuals or companies will simply find it hard to survive without System 1 - unless they already had a lot of capacity and capability built up. Unfortunately many get comfortable using System 1

System 2 works for Products (includes SaaS) and chances are that it mostly works for Products that have been slightly successful in the first place. This is where you also find consulting companies that may have obnoxious rates.

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

#126

Post by denzil_correa »

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…

> If you can plan and execute putting a person on the moon, you can plan and execute software development.

Do we have the planning and estimates of projects that are similar to "put people on the moon"? I'd like to see how the plan/estimates of these projects look like and how they change.

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

#127

Post by vineet »

avip wrote: post #113
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…

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 if I ask you how long it takes to build a Wordpress blog for a music band, based on your experience building blogs for realtors. You guess will likely be good enough for me. :-)

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

#128

Post by jfoutz »

avip wrote: post #113
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…

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.

But then you say go for it and get upset about all the time I spend getting a passport, booking flights, and figuring out how to transport the ice cream back.

I’m kidding, of course. It really depends on how well business and development understand each other.

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

#129

Post by jillesvangurp »

There's a lot of snake oil for sale if you are looking to spend money on solving this problem; this probably is more of that.

The reality is that mostly we've gotten better at avoiding things that clearly don't work or are historically obviously misguided/inappropriately expensive (waterfall, CMM level 5, etc); and instead emphasizing things that don't work slightly better: managing risk by doing iterations, not attempting to plan the unplannable eventualities too far ahead of time, etc.

Some people refer to this as Agile. Other people as common sense. Either way, not wasting time on things that clearly don't add value tends to free people up to do something productive (duh). There's a pattern with agile with mostly non technical people higher up the management chain getting overly excited about things like estimates, velocity, burn charts, etc. I usually call stuff like that the illusion of progress and waterfall in disguise. Scrum particularly seems to have devolved to decorating offices with post its and employing busy looking people with moving those around and manually tracking them in convoluted tools like Jira.

But undeniably, we've gotten better over the past decades at building stuff with huge groups of people. Any idiot can probably gobble together some lines of code that does something vaguely useful. But committing to building stuff with hundreds or thousands of people is a different game. It requires lots of money and focus and there are quite a few companies that are doing this successfully.

A bigger pattern in our industry is that people seem to have shifted to calendar driven roadmaps for the most important bits of software where they ship whatever is ready on a fixed dates instead of committing to a long list of stuff shipping whenever it is ready. E.g. Apple ships OS versions once a year, Mozilla, Linux, Chrome, etc. ship every few months, typically with massive amounts of code changes.

Post reply on HN