Planning and estimating large-scale software projects • Hacker News Board

Re: Planning and estimating large-scale software projects

#61

Post by x0x0 » Wed, Jul 21, 2021, 6:52 PM UTC

andruby wrote: post #53

ColinHayhurst wrote: post #10

> Estimates are one of the hardest parts of software development. And also fundamental. When I was directly estimating big software projects the key, for me, was to trust developers recommendations but apply a different multiplier for each developer. Multipliers ranged from x1 to x3. Those rare devs with x1 were, of course, a blessing. And those with x3 were not necessarily bad; they were often the ones working on th…

Do you mind explaining why you say estimating is fundamental? I don’t disagree that it is important, I probably wouldn’t label it as fundamental, at least in a context of a company developing its own software internally.

It's one of the top two or three most important things.

All teams have far more work than they can possibly do. A handful of things win; most things lose. Reasonable cost tradeoffs to pick which two or three things per quarter get worked on require estimates. And even in small startups, millions of dollars are spent on salaries per those decisions.

Re: Planning and estimating large-scale software projects

#62

Post by stingraycharles » Wed, Jul 21, 2021, 6:56 PM UTC

commandlinefan wrote: post #57

mason55 wrote: post #50

Earlier quoted context omitted.

One thing I’ve found to be helpful is to make it clear that I won’t be mad about a long estimate If that’s how long it’s going to take then that’s how long it’s going to take. I think there’s a group of people who are used to getting lots of pushback on their estimates and so they estimate low to avoid that conflict. The future conflict of things being late is not something they have to deal with right now and maybe…

> I won’t be mad about a long estimate So... my experience with this mindset is that you won't be mad , but you'll just say "that's too long/expensive" and cancel the project entirely. Then the same project will come up again in two months with different wording, again and again, until I give you the estimate you think you can afford. And then the thing will end up taking longer than the original "too expensive" esti…

I think this attitude is too fatalistic. A good approach would be to see if there’s some way to break up the feature in smaller pieces, into smaller milestones, etc.

If you have a manager that is unable to deal with this kind of stuff, then your problem is the manager, not the estimates. Estimates are extremely useful, and you’re doing yourself a disfavor if you think that they are never meaningful.

Re: Planning and estimating large-scale software projects

#63

Post by satyrnein » Wed, Jul 21, 2021, 6:57 PM UTC

dragonwriter wrote: post #41

crazy1van wrote: post #39

Earlier quoted context omitted.

> it's a guess and can never be anything but a guess Of course it's a guess. The question is how to make more accurate guesses.

> The question is how to make more accurate guesses. I think the question should be about how to maximize the net return on time dedicated to development, which may mean spending less time on (and investing less reliance on) estimates rather than expending unbounded effort improving the quality of estimates.

What's the value to Sales/Marketing/etc of knowing what's coming when? How do you estimate that? It's estimates all the way down!

Re: Planning and estimating large-scale software projects

#64

Post by majormajor » Wed, Jul 21, 2021, 6:57 PM UTC

commandlinefan wrote: post #57

mason55 wrote: post #50

Earlier quoted context omitted.

One thing I’ve found to be helpful is to make it clear that I won’t be mad about a long estimate If that’s how long it’s going to take then that’s how long it’s going to take. I think there’s a group of people who are used to getting lots of pushback on their estimates and so they estimate low to avoid that conflict. The future conflict of things being late is not something they have to deal with right now and maybe…

> I won’t be mad about a long estimate So... my experience with this mindset is that you won't be mad , but you'll just say "that's too long/expensive" and cancel the project entirely. Then the same project will come up again in two months with different wording, again and again, until I give you the estimate you think you can afford. And then the thing will end up taking longer than the original "too expensive" esti…

I've seen this, but I don't think it was a problem or a bad thing.

Let's say the project was first proposed in January 2021. Got estimated as taking a year. Didn't get scheduled, since that was seen as too long, and there was other stuff people wanted done in 2021.

It's pitched again in June 2021. Same story.

Come Feburary 2022, it's pitched again. Now it's estimated as 15 months - there's more to do since more code has been written in the meantime! - and gets started, and ends up taking 19 months (estimates are never perfect!).

You might say "this was stupid, we should've just done it in January 2021" but in the cases I've seen, pushing it off a few times made perfect sense. The payoff wasn't seen as the most valuable thing that could be done, and the effort was high. The effort became higher after it was postponed, but by that point so was the relative value compared to other proposed projects.

On the other hand, if you hadn't come up with that first estimate, maybe the assumption is "ok this will take several months but we'll still be able to do this other stuff in 2021", but instead you work on it throughout 2021 and ship it in March 2022 or so (so ~15 months, still faster than doing it later), but that causes you to not do 80% of those other things you thought you could do.

Postponement or cancellation of a project because it's just too expensive to be worth it right now is a perfectly valid use of an estimate!

Re: Planning and estimating large-scale software projects

#65

Post by ksec » Wed, Jul 21, 2021, 7:04 PM UTC

kalleth wrote: post #2

Author here. I've been lucky enough in my career to hold some senior positions, and I thought I'd give a step-by-step on an approach I took with an "enterprise-scale" software project, and how I stole some techniques from university project management courses to meet with some success. Happy to answer any questions :)

Do you think there is a different in how US and UK tech companies in project planning?

Re: Planning and estimating large-scale software projects

#66

Post by RogerL » Wed, Jul 21, 2021, 7:09 PM UTC

kalleth wrote: post #19

antondd wrote: post #14

This brings back memories from the days of my early career (an ex-PM survivor here). I would be curious to see some data, even anecdotal, on the success of this approach. Here's some interesting statistics from the industry (not specific to software, but you can extrapolate): http://apepm.co.uk/project-management-statistics/ In my view, traditional software project management is ineffective. I would put it somewhere…

Insightful, thank you! The entire project management industry doesn't have that great a "hit rate" -- consider the budget overruns for the last few Olympics, or for Crossrail. I'm just not sure why software projects are "special" -- if you can avoid it being a project and instead make it ongoing OpEx like, for example, GDS managed for the UK in 2016, then great, you've sidestepped that, but until the entire PM indust…

It's not special, except that for whatever reason people insist on treating random data as gospel.

How long until we cure retinoblastoma? Everyone understands there is no way to produce a meaningful timeline. There are too many inter-related unknowns - various causes, various treatment modalities, varying funding on various fundamental and applied research, no real idea if the final answer is gene therapy, nano-something, chemo, etc.

I used to develop software for a defense contractor, and it was pretty waterfall-y. But we built risks in, to an extent. Not by multiplying Sally by 1.3x, Joe by 2.7x or whatever, but you'd chart it all out, showing interconnections (x depends on Y, which depends on Z and Q, which...). And then roughly figure out risks of each of those sub-tasks going long.

The idea NOT being you then just multiply by a weight, and ta-da, you have an accurate schedule. The idea is that you have now identified particularly risky chain of events, and now you at least have a chance of managing risk. Every day/week you'd have a risk assessment meeting. Where are we on X, Y, Z. What can we do to get X back on track? Can't, okay, can we we-jigger the dependencies, or is this a hard slip? And so on. I've never seen this done on the commercial side, and it just seems like people are flying blind as a result.

"Waterfall is terrible" you reply. Sure. But when you are building an airplane, ya kinda need the 1553B/ARINC bus installed before you install and test the avionics. You can't attach the engines if the wings haven't shown up. You can't redesign the fuselage after the wing builder started building the wings (in general). These are hard, unavoidable dependencies, and changes are often extremely to destructively expensive (hence the endless mind numbing meetings arguing about change control).

It is just (IMO) not an unsolved problem, but unsolvable. Too many unknowns results in unpredictability. Your only bet is to manage the risks, adjust as necessary, and accept some things are just unknowable. Agile does that in one way, sophisticated waterfall in another.

Re: Planning and estimating large-scale software projects

#67

Post by majormajor » Wed, Jul 21, 2021, 7:12 PM UTC

andruby wrote: post #53

ColinHayhurst wrote: post #10

> Estimates are one of the hardest parts of software development. And also fundamental. When I was directly estimating big software projects the key, for me, was to trust developers recommendations but apply a different multiplier for each developer. Multipliers ranged from x1 to x3. Those rare devs with x1 were, of course, a blessing. And those with x3 were not necessarily bad; they were often the ones working on th…

Do you mind explaining why you say estimating is fundamental? I don’t disagree that it is important, I probably wouldn’t label it as fundamental, at least in a context of a company developing its own software internally.

Even when developing your own stuff internally, you have a limited resource: your dev team's capacity to do work.

The most important question for your internal software team is still "what should we work on" and estimates are a fundamental part of answering that.

It's someone's job to figure out what things that team could do to provide the highest value. Usually some combo of product/sales/marketing/tech.

But that's only half the equation! You also want to know how much it's going to cost, in terms of those scarce dev resources. If one project would add X value but take a year, and another set of projects would add Y, Z, and A value, but each only take four months, you want to compare Y+Z+A vs X to see what gets you the most value over the next year. So the better the estimates, the more rational you can be about what work gets done. If you have no estimates, you might pick a project that will go on for way too long, and not get the value out of it that you expected.

(However, I doubt anywhere truly uses NO estimates. I've never seen a place that didn't at least have an informal level like "oh that'll be really hard" or "that'll take us a long time.")

Re: Planning and estimating large-scale software projects

#68

Post by commandlinefan » Wed, Jul 21, 2021, 7:18 PM UTC

stingraycharles wrote: post #62

commandlinefan wrote: post #57

Earlier quoted context omitted.

> I won’t be mad about a long estimate So... my experience with this mindset is that you won't be mad , but you'll just say "that's too long/expensive" and cancel the project entirely. Then the same project will come up again in two months with different wording, again and again, until I give you the estimate you think you can afford. And then the thing will end up taking longer than the original "too expensive" esti…

I think this attitude is too fatalistic. A good approach would be to see if there’s some way to break up the feature in smaller pieces, into smaller milestones, etc. If you have a manager that is unable to deal with this kind of stuff, then your problem is the manager, not the estimates. Estimates are extremely useful, and you’re doing yourself a disfavor if you think that they are never meaningful.

If I was surrounded by people who could put together accurate software estimates that made upper management happy, and I was the only one who was always got it wrong, I'd hang up my hat and see if I could get a job selling life insurance. Hell, if 10% of my peers could put together accurate software estimates that made upper management happy, I'd lobby to have them elevated to senior positions and spend all my time begging them to explain their secrets.

But they don't. Nobody does. They don't just get the timelines wrong, they get the tasks and milestones wrong - which makes sense, because the people asking for the estimates don't actually know what the goals are, usually even after the software is delivered.

The only thing an intelligent software developer can do is play along, learn to read subtle cues as to what they want you to say, say that, and get on with the actually messy business of delivering working software.

Re: Planning and estimating large-scale software projects

#69

Post by kalleth » Wed, Jul 21, 2021, 7:18 PM UTC

ksec wrote: post #65

kalleth wrote: post #2

Author here. I've been lucky enough in my career to hold some senior positions, and I thought I'd give a step-by-step on an approach I took with an "enterprise-scale" software project, and how I stole some techniques from university project management courses to meet with some success. Happy to answer any questions :)

Do you think there is a different in how US and UK tech companies in project planning?

I've never worked for a US tech company, so I wouldn't know, sorry!

Re: Planning and estimating large-scale software projects

#70

Post by kalleth » Wed, Jul 21, 2021, 7:19 PM UTC

pphysch wrote: post #58

There are arguably two major phases here, and its only the second one that most folks here find controversial. * Steps 0-2: determining "what" the project "is" (design, architecture, ontology) * Steps 3-6: procuring and allocating resources to complete it (economics, management, politics) It is tempting to decouple the two phases, and as a technologist focusing solely on architecture while leaving the economics up to…

Well phrased, thank you! I didn't think of it in this way, but yes, that kind of phasing makes sense.