Live data from Hacker News

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

7pace.com

11–20 of 239 posts

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

#11

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…

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.

Engineers hate releasing poor quality products, but the reality is that customers often will buy and use something laden with defects rather than nothing at all. And in any case, after the initial botched release, you can always fix stuff. See Apple.

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

#13

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…

Director who still writes code here. You're correct, but there is a vicious cycle here: when a project is delivered late, some managers respond (incorrectly) by artificially tightening the next deadline, hoping that when the team invariably slip, it'll at least get delivered by the original deadline. This never happens. The team does hasty planning and dives into implementation as soon as possible (to save time) and ends up delivering even later.

What worked for us is what's basically mentioned in the article: taking a more structured, slightly painstaking approach to estimation. It's more tedious than gut feel story point estimation, but a lot less painful towards the end of the project.

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

#14
> This is where System 2 comes in—if we performed a more thorough analysis, these factors would have been considered in our answer. Then it would be clear that it’s much more likely to take 20 or 30 minutes to run to the store instead of 10.

I have encountered an article (can't find the link now, sadly) that claimed that when developers gave estimations, breaking down tasks to sub-tasks actually had a reverse correlation to their accuracy. In other words, their first gut reactions were actually better than estimations given after going in-depth through all the details and sub-tasks.

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

#15
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…

Wholeheartedly agree with #1. I'm fond of saying, "If it takes longer than four hours, you probably haven't broken it down enough. Find the monsters hiding inside your big tasks."

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

#16

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…

Software is up there as the most complex thing ever created. People have been putting up houses for thousands of years, And modern big bridges for hundreds. Big software is ~40-60 years old. Its hard to have rules of thumb and best practice that will deliver the 'on time outcome'. Give it another 100 years.

Most dev work right now is still just attempting to deliver correct software. let alone on time or on budget.

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

#17
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…

How do you create this detailed plan? Are there any tools or frameworks?

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

#18

As a long time engineer, and occasional pm. I steer teams to think about the worst case, and then triple that time estimate. I know this sounds like setting up a team for failure, but I’ve seen it work again and again. It sets clear expectations for quality and delivery upwards and downwards which everyone can agree on. Once this is done, the easier part is keeping everyone focused, and using all the leftover time we…

I often ask people when they think it will be done and then multiply that number by five. It works pretty well :)

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

#20
post #4

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…

I'm a software developer, and I know this is a bit heretical to say, but I think sometimes we need to set goals that are overly ambitious so that we can work hard to meet them, even if we end up being late. I've been a contractor to a couple companies that didn't have real goals and there is this kinda easy going attitude that results in many things taking 4x as long as they could and often a lot more office politics…

My experience, a ‘my goal’ gets quickly interpreted as ‘you committed to this’. ‘I can try’ projected as ‘You said you will get this done’. I’m all in for trying my level best and I have seen the rare slip ups penalized, criticized and highlighted to such a degree that it is just irrational for any dev to ‘try’ or be ‘ambitious’.
Post reply on HN