Why Development Teams Struggle to Deliver on Time, on Budget, or at All • Hacker News Board

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

#111

Post by ThrowawayR2 » Tue, Jun 05, 2018, 3:57 PM UTC

jhall1468 wrote: post #39

ttul wrote: post #11

Earlier quoted context omitted.

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

> the tech titans that suffer from the exact same problems

The tech titans aren't monoliths with a collective hive-mind. Each business unit and team is responsible for projecting revenue targets and then hitting them, same as any other kind of business. And, yes, if the business unit managers fail to hit their financial goals too many times, their project will be cut and the team reassigned or laid off, same as a startup running out of financial runway.

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

#112

Post by harryf » Tue, Jun 05, 2018, 3:58 PM UTC

snowwolf wrote: post #73

So the author of this has a vested interest in their "solution" being the correct one, but I fundamentally disagree with it. I agree with their hypothesis that we are bad at planning/estimating, but the solution is not spending more time on it, but rather less. Firstly I really like this humorous look at the problem: https://www.quora.com/Why-are-software-development-task-esti... You cannot estimate what you don't kn…

> 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 deterministic and quantifiable.

Example: when Apple opened the App Store to 3rd party developers, would it be realistic to expert an accurate estimate from one of those developers, building their first app? There were so many unknowns; how does the build / publish process work? what will pass the review process? what about all these new APIs?

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

#113

Post by avip » Tue, Jun 05, 2018, 3:58 PM UTC

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…

Yet if I ask you how long it takes to buy icecream in Japan, based on your experience grabbing milk in the US, your guess will be "less than half a day". Which is good enough for me.

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

#114

Post by zer00eyz » Tue, Jun 05, 2018, 3:58 PM UTC

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…

> When the VP sets a deadline - it’s driven by the survival of the company

This is everything that is wrong with software.

What is software really? It is translation of business process and need into code - I spent the first 10 years of my work life mastering code, I will spend the rest of it understanding whatever business I'm working for.

Assuming you have some experienced engineers (not mangers) on your staff then having the vp set a date (and defacto choose the project) is absolutely backwards.

Bring the problem to your engineers (money) and don't look for a moon shot look for 10 smaller projects that get you 1/2 way to the goal in 1/10th the time. Don't think of it as a "hack day" think of it as a hack week or hack month.

If you have a large project and it is to "save the company" (or push it forward) and your treating it like a must do rather than a foundation (and taking care) your creating debt and starting a cycle that you will never pay off.

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

#115

Post by lostcolony » Tue, Jun 05, 2018, 3:59 PM UTC

mirceal wrote: post #76

lostcolony wrote: post #50

Earlier quoted context omitted.

This is why agile tries to push the business stakeholders to define -problems- rather than -solutions-. Developers then try and come up with a solution, and pitch it to the business (effectively). Almost every issue I've had with the business/developer dichotomy (and I use that instead of product because different orgs place product differently) has been due to the business trying to pitch solutions to dev that invar…

Maybe, maybe not. I’m very suspicious of things that are pitched as a panacea for everything. The real world is a messy place where even with a good team, a good plan and sensible expectations you can fail spectacularly. If there is one thing that I really like is aggressive validation of the assumptions that are being made + keeping the product as small and lean as humanly possible (and the latter should apply acros…

Oh, I'm not saying it's a panacea for everything. Just that most issues I've seen along these lines were also accompanied with a perspective on the business side that their role was to give solutions, which were invariably insufficient, led to the dev team just doing the minimum (since they had no idea what the core problem was and thus were unable to determine where 'sufficient' really was), and that compounded.

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

#116

Post by dmichulke » Tue, Jun 05, 2018, 3:59 PM UTC

sonnyblarney wrote: post #61

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

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

#117

Post by handbanana » Tue, Jun 05, 2018, 4:01 PM UTC

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

Okay, but I think you've missed the point. Planning is hard, and you can't possibly account for all the variables.

Everything after that statement I can agree with

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

#118

Post by himynameisdom » Tue, Jun 05, 2018, 4:02 PM UTC

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…

To be fair, Scrum doesn't try to capture development time estimates, only the effort needed to provide value. Work items inherently vary in size, or estimated effort. However, enough work should be planned during planning for the dev team to forecast what it believes it can do in the upcoming Sprint. It's all about transparency, not adherence.

That said, requirements emerge daily. Transparency is essential for honest dialogue.

I agree and disagree with the notion that an estimate can only be provided after the work is done. If the work is broken down properly, you can use empiricism to get a good understanding of what is needed based on previous, similar work completed. But to think an estimate can only be provided after the work itself is done is kind of ridiculous. If you section off variables with manageably-sized work you should have a good understanding of what's needed to pull it off.

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

#119

Post by harryf » Tue, Jun 05, 2018, 4:04 PM UTC

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

I think you vastly overestimate the quality of the software and systems that took men to the moon. Try reading https://www.google.com/amp/s/amp.space.com/26593-apollo-11-m... for example - you might conclude "they got lucky"

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

#120

Post by supreme_sublime » Tue, Jun 05, 2018, 4:05 PM UTC

__dontom__ wrote: post #92

wildekek wrote: post #35

Higher up manager here. I fully accepted the #noestimates movement and it is a complete blessing for all the teams and organizations I've implemented it in. Roast me.

Did you do that in an agency as well? I mean it's one thing if you are developing a product, but telling your clients "the project is finished when it's finished and we won't be able to tell you how much it will cost you until it's finished" doesn't really fly in my experience.

Seems like charging a specific fee might help alleviate some of the concerns about that. Though I suppose you still need to know how much money you should charge.

I really hate estimates and have always hated estimating projects. I do appreciate the need/desire for them by some in management. I've tried to figure out how other people do it and have yet to find anything satisfactory. It doesn't have to be an extremely simple process, but I don't really know how one gets better at estimating. The only way to get better is to just understand the domain more clearly but estimating doesn't really help with that.

Kanban does have a cool idea of just attempting to break down work into equal parts and measuring the throughput of these roughly equally sized components. The only problem is actually sizing stories to be equally sized. Some changes don't have any kind of real stopping point of functionality without large changes. It seems kind of arbitrary to chunk it out just because your project management system wants you to.