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

101–110 of 239 posts

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

#101

Post by chiefalchemist »

If you __really__ don't get to set the deadline, is it still reasonable to held accountable for that miss? Even if you give worst case and best case the only one anyone else focuses on it best case.

Personally, I prefer the 80/20 rule. That is most of the work will go fair quickly, or at least uneventful. It's the last bit that's always the killer. The devil is in the details, as they say.

When asked for an estimate we quickly identify the 80. The key is to pause and not write off the remaining 20.

p.s. Early in my career I read somewhere (I wish I couple remember where) something along the lines of:

Alomst everything takes twice as long and costs twice as much as your original estimate.

If I had $20 for every time I found that to he true, I wouldn't have time for HN. I'd be too busy counting my money.

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

#102

Post by Aaargh20318 »

jungturk wrote: post #81
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…

> 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 ?

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

#103

Post by Shivetya »

One missing element is the failure to allow teams or their members to stay on the project. It is very common to see people pulled off to must haves, support needs, and even many projects totally skip out on accounting for staff vacations which can be costly with long term employees who have four to six weeks out.

It is so easy to come across the frustrated developer, frustrated that they just cannot be allowed to do the work.

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

#104

Post by toasterlovin »

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.

But the budget for planning is limited. To realistically plan out most software projects would entail almost as much work as simply executing on them. That level of resources for planning vs. execution is acceptable for putting people on the moon. Probably not for building a line of business app.

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

#105

Post by chiefalchemist »

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…

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.

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

#106

Post by cm2187 »

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…

I'd add #3: over-engineering. 90% of the time a simple quick solution will be as good as a super sophisticated and abstracted solution that will be delivered 1 years later, when the underlying problem it is trying to solve has changed (cf the usual tree swing cartoon [1]).

[1] https://www.tamingdata.com/wp-content/uploads/2010/07/tree-s...

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

#107

Post by [deleted] »

chii wrote: post #5
jhall1468 wrote: post #3

In my experience, deadlines set by higher-ups long removed from (or never having) the technical chops to be determining the deadlines in the first place. VP's and Directors are often the ones dictating the direction, which is great, but then also introducing deadlines, with helpful input from Directors who ALSO haven't touched code in many years. Generally that results in one of two things: * Product delivered on-tim…

In the beginning was the Plan. And then came the Assumptions. And the Assumptions were without form. And darkness was upon the face of the Workers. And they spoke among themselves, saying, "It is a crock of shit, and it stinketh." And the workers went unto their Supervisors and said, "It is a pail of dung, and none may abide the odour thereof." And the Supervisors went unto their Managers, saying, "It is a container…

[deleted]

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

#108

Post by markkanof »

commandlinefan wrote: post #78
bazooka_penguin wrote: post #21

Earlier quoted context omitted.

How do you estimate how much time a task will take, especially when it's a novel idea, at least for your developers?

> How do you estimate how much time a task will take when it's a novel idea In my experience, they just pretend it doesn't exist and remove it from the "plan". Where I see this the most is in figuring out how things work. For some reason, non-programmers have it in their head that once you've finished college, you ought to know (even though they don't) how everything that goes on a computer works instantaneously. We'…

You hit on one of my favorite gems, "Bob has done something like that before, just ask him how to do it." The manager is envisioning that the team already possesses the knowledge necessary to get the task done, so there should be zero learning time involved. What this is missing though is that Bob isn't going to be solving the problem for the current task AND/OR Bob didn't even solve a similar problem, he just used the same tool or library that is now being used for the current task. If we had a Matrix like ability to instantanously transfer knowledge then this approach might work, but we aren't there yet.

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

#109

Post by wvenable »

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…

You've missed the point. Nobody can (or did) accurately estimate how long the planning and development would take to get someone on the moon. Half the materials weren't even invented yet in 1962. Nobody knew that Velcro was flammable in pure oxygen.

Sure once all that expensive and unknowable planning and development is done, you can double-click that executable and put a man on the moon.

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

#110

Post by fizixer »

Complexity is not as democratizable as the industry likes to believe.

- an org-chart team of 100 will perform worse than a tightly knit team of 10

- a tightly knit team of 10 will perform worse if tangible results are expected on regular intervals of the choosing of managers (e.g., weekly, monthly, take your pick) as opposed to treating the software project as a computer science research project spanning a year or more.

- a tightly knit team of 10 working on a software research project spanning a year or more will perform worse if expected to succeed in their first attempt as opposed to allowing them to fail one or more times and change directions, maybe even starting from scratch every time.

Post reply on HN