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

31–40 of 239 posts

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

#31

Post by makmanalp »

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…

My god, this is spot on.

Re #1, this is kinda the system 2 vs 1 thing in the article. I was lucky enough to have a PM drill me into this. More specifically: The bigger a task is, the likelier it's going to go over time. The bigger a task is, also the less likely each bit is well specified and more likely that there are significant portions glossed over that you'll discover during implementation, which will delay things and/or result in them being done poorly. If you're having a hard time breaking the task down, it's probably because the task isn't well defined enough, so go back to stakeholders and define better. In this model, planning takes a lot of time and effort. Also in this model, research-y tasks are different, and instead get a fixed timebox after which you have to re-decide how much more time to spend on it if at all.

Re #2, part of the problem here I think is that PMs aren't trusted / empowered with that ability or final say. "Stakeholders" get to make that decision, but with ignorance of what it's currently like in the trenches.

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

#32

Post by sh87 »

hliyan wrote: post #15
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…

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

I’ve seen concerns and FUD over getting lost in too many tasks. How do you manage the overhead of 20 4-hour tasks against 2-3 high level tasks?

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

#33

Post by mirceal »

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

You break it down (effectively doing the work) as part of planning and after that you pretend that you have a working system. Make sure not to go into details and/or “take it offline” until the developer is tired/annoyed enough to just agree with you pipe-dream estimates /s

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

#34

Post by agalaxynearby »

Do you really want to know why some development teams struggle to deliver on time, budget or at all? Because the majority of software projects out there are utter useless crap, commissioned by people who have no idea what the heck they are doing and focus on the smallest stupidest details, before even getting a decent amount of users or even wondering whether users would like those changes (before implementing them). People who, once the money runs out, will make the project crumble, frustrate developers who have to reimplement the same stupid piece of logic 20 times because "that button looks too big" or "this would be a really cool animation to have" while everything else goes to shit.

We get into software development because we expect it to be a creative, challenging and fun profession that creates value and yet most of us answer to clients or employers who expect us to spend 80-90% of our time working on boring, senseless stuff. You want us to do that? Great! But don't expect high quality and on time delivery.

The real reason behind delays is that we just don't give a crap about your "social network for cows" and we can't wait to save enough money to get the fuck out and either start a business, work for a decent company or start investing.

Apologies but it feels good to rant every once in a while.

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

#36

Post by grigjd3 »

I hate it when PMs ask me for an estimate of effort on a task I have never done before and I get this question all the time. I get asked to get a new process through a deployment system I've never worked with before and that's fine. How long will it take? That depends on how complex the deployment system is and I haven't worked with it yet.

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

#37

Post by ibdf »

When I first started working as a web developer, my boss would ask me how long it would take to finish a project. I would give him an estimate time, and he would always double it. As it turns out he was always right. But because of it, I learned to provide better time estimates. Overtime I became more accurate and started to provide more realistic time frames. Depending where you work or who you work with there's a lot more that goes into your day to day tasks than just coding.

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

#38

Post by wolco »

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…

Moving milestones, incomplete requirements, too many meetings, wrong tech stack, trying to break everything into halfdays to fit an agile agenda.

What does work is waterfall. Whatever is in the repo at the end gets shipped.

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

#39

Post by jhall1468 »

ttul wrote: post #11
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…

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…

That's a fine argument for a bootstrapped startup with one product, but isn't meaningful when talking about the tech titans that suffer from the exact same problems.

This is the same type of argument that makes short-term profit take precedence over long-term success. Why in the world are we getting a deadline of 4 months? You, as an executive, had to know burn rate was blowing through cash a lot earlier than that.

Engineers hate releasing poor quality products because we know we'll eventually have to fix them and we will likely be given almost no leeway time-wise to fix the actual debt, as time will always favor ugly hacks that "work" over well-written code that prevents the problem in the future.

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

#40

Post by LargeWu »

ttul wrote: post #11
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…

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…

Have you considered maybe you're treating your engineers like children? Why aren't they cognizant of the business realities? If they aren't on the same page as the business side, that's poor leadership on your part. I think everybody can appreciate that in order to keep the lights on sometimes you need to be in crisis mode, but if the company perpetually operates in crisis mode, then maybe the engineers aren't the problem.

Here's the reality, and maybe you've forgotten: The engineers are the ones who are going to get dumped on, and you and the VP's are the ones who are going to reap the benefits. Never forget that.

Post reply on HN