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

181–190 of 239 posts

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

#181

Post by bittcto »

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…

If you have deadlines, you already know management is incompetent.

Deadlines presume a known fixed scope. But I’ve yet to meet a CEO or sales team or whomever gets to decide what features go in who will fix the scope if a project.

They are always willing to add features, but can never take them out.

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

#182

Post by bittcto »

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.

The problem is that product and dev are different people. Product managers don’t understand their product as well as the devs do. devs should manage the product definition and work with feature requesters at a very high level, where the details are the choices of the devs (or senior devs acting as product managers.)

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

#183

Post by 3pt14159 »

eckza wrote: post #8
3pt14159 wrote: post #4

Earlier quoted context omitted.

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…

I disagree. We need to set realistic goals so that we can work hard to meet them. The mindset you are describing is part of the reasons that we have these problems in the first place.

I'm open to having my mind changed, but I've rarely been on projects that ended on time that ended as quickly as they could have.

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

#184

Post by AstralStorm »

dmichulke wrote: post #116
sonnyblarney wrote: post #61

Earlier quoted context omitted.

I have to respectfully disagree with #1. Software is hard because we 'don't know the unknowns'. It's not like building a building - if it were, we could just schedule it down to each detail. We would be still all be using 'waterfall'. If we knew how to write the module, we'd just do it, test it, and voila. But most of our time is spent 'figuring stuff out'. Oh, product has asked for a tiny change (support a specific…

> The other major unspoken factor is that requirements change Walking on water and developing software from a specification are easy - if both are frozen - Edward Berard

Also when the dependencies are frozen. If these change, you're walking on mud. It sucks.

Comparably it'd be as if building developer built from prefab that changes the design every week.

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

#185

Post by AstralStorm »

kbuchanan wrote: post #23
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'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 reciprocate…

This approach does not scale to maintenance. You cannot strike down anything when maintaining and/or porting. (And it is risky to even cut testing.)

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

#186

Post by AstralStorm »

cm2187 wrote: post #106
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...

Sometimes. And then someone adds layers and layers of crud on a "simple thing" because nobody actually engineered it.

And then some poor soul gets to rework all this...

Basic abstractions help a lot. Specifically, having things weakly coupled.

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

#187

Post by ItsMe000001 »

kareemm wrote: post #174
ItsMe000001 wrote: post #163

Earlier quoted context omitted.

When I read that in OPs comment I immediately had to think of "How to draw an owl" (the meme version, not one of the serious online lessons -- https://pbs.twimg.com/media/DcC1YEyVQAA9Lkw.jpg ). "You simply break the task down into all its parts, then you just do it. Projects are easy." Not to mention that that approach only works if you produce another version of something you already produced many times. There certa…

> Planning well, finding out what to do, is harder than the actual programming. Again and again, in all projects, I find that the >90% part is finding out what to do. There So you've advocating an approach where you... don't plan? I'm confused. Perhaps you're getting too hung up on the half day part? That measure is a useful forcing function that ensures the dev team has thought through the approach in enough detail…

http://dilbert.com/strip/2015-06-07

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

#188

Post by AstralStorm »

softawre wrote: post #142
harryf wrote: post #112

Earlier quoted context omitted.

> You cannot estimate what you don't know Exactly! It tried to express that and a strategy for handling unknowns here - https://medium.com/@hfuecks/what-donald-rumsfeld-can-teach-u... My theory is the reason why we’re not getting any better at estimating software projects rests on a flawed assumption; because computers are binary and deterministic, we assume that the process of creating software must also be determin…

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

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

#189

Post by mirceal »

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.

you're not alone. I would say that lack of trust is the norm not the exception when it comes to software dev teams :(

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

#190

Post by root_axis »

kqvamxurcagg wrote: post #17
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…

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

I'm a big fan of arc42
Post reply on HN