Live data from Hacker News

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

7pace.com

21–30 of 239 posts

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

#21
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 estimate how much time a task will take, especially when it's a novel idea, at least for your developers?

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

#23
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'll also wholeheartedly agree with this comment—my company has a long history of shipping on time and under budget. The caveat is that we closely follow #2: we aggressively strike requirements from the overall target if it means preserving the integrity of the project overall, with a commitment to return later.

I'll add this: a product team that ships earns 1) more credibility, and 2) that credibility is reciprocated towards the team in the form of greater flexibility and freedom to set their own targets.

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

#24
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 estimate how much time a task will take, especially when it's a novel idea, at least for your developers?

You don't. That's the thing. Yet decision makers commit to deadlines anyway, and that's the problem.

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

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

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

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

#26
post #2

OT: I like the "thinking systems" infographic but the fact that the green areas are few pixels off is annoying me to no end. I hope it's not a new trend.

"to no end" means: uselessly. "no end" means: endlessly.

Thanks, wasn't aware of that.

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

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

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 waaaay more optimistic about how much it takes to do the work.

How do you fix it? Trust and ownership. Product and Dev need to have an interface - a boundry if you will - and the discussions and talk are about defining this interface and setting expectations. Product trusts Dev on implementation. Dev owns the delivery and makes it happen.

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

#29
post #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. Engi…

I agree with you in part. However, engineers are more than capable to also take into account for planning the survival of the company if management provides the proper data to them. I think this is one of the problems, management usually hides information from the people they manage and without that data certainly plans can go in the wrong direction.

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

#30
Having been involved professionally in software development for about 14 years now, I have to say I respectfully disagree. More planning does not result in better predictions. In fact, it often results in worse ones. That is just my empirical observation.

My best guess as to why, is that there are managers involved that attempt to negotiate the planned delivery time down. They do this, in part, because it's hard to get devs to work late or on the weekend when the project is on schedule, but easier to do when there is obvious risk of falling behind schedule. So, from their point of view, the best way to get the product delivered early is to get the schedule made too optimistically.

Not saying they SHOULD do this, or even that they are consciously thinking this way, but it's what the situation incentivizes them to do, and it's what normally happens. The gut level immediate answer is based on past experience, and the long drawn out meeting produced, System 2 answer, is based on management bargaining the developers down to a shorter timeline.

Post reply on HN