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

Re: Planning and estimating large-scale software projects

#41

Post by dragonwriter » Wed, Jul 21, 2021, 5:41 PM UTC

crazy1van wrote: post #39

henning wrote: post #25

Bullshit. You can make guesses about the future, but since that is going to inevitably change, it's a guess and can never be anything but a guess. At most companies, the scope is going to be radically expanded and looking too far in the future is a complete waste of time. Other people in other fields are held accountable for deadlines because their work does not completely change and is not severely under-specified.…

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

Re: Planning and estimating large-scale software projects

#42

Post by marcus_holmes » Wed, Jul 21, 2021, 5:42 PM UTC

NikolaNovak wrote: post #32

marcus_holmes wrote: post #28

Earlier quoted context omitted.

Early in my career I had this. I was given a task and a deadline, and told to prepare a plan. I estimated the plan, and it came out to longer than the deadline. I presented this, only to be told "but that's longer than the deadline! go fix it!". So I shortened all the estimates and it fit the deadline. When I presented this I was shouted at for shortening all the estimates, and told to go back and do it properly. Aro…

Unfortunate; most of us have had experienced such situations separately, it sucks when they come together in a "rock and hard place" situation. Good managers / business leads/ execs / champions CAN be reasoned with, as long as you find common language, think and understand their priorities, provide alternatives that meet their underlying goals (all of which frequently falls on the presenters). E.g. in your situation,…

> understand/ask/bring to surface everybody's actual critical goals

This, exactly. Now I'd be working out what the actual objective is and how I can achieve that.

Re: Planning and estimating large-scale software projects

#43

Post by mzarate06 » Wed, Jul 21, 2021, 5:44 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 :)

I'm curious that you mention project management courses from university. How much benefit have you found them to provide in practice?

Asking b/c I've taken two courses in dev process or project management in my academic career, and neither provided substantial value or benefit to how I've lead projects professionally.

Re: Planning and estimating large-scale software projects

#44

Post by RandomLensman » Wed, Jul 21, 2021, 5:45 PM UTC

agentultra wrote: post #8

This is a great breakdown of your process. I've seen many quite like it and have also been asked to make these kinds of estimates myself on projects for many of the same reasons: someone made a promise to another person, signed a contract, planned a release date for something they just made up, etc. What I find frustrating about the whole situation is that no matter what process you use for making these estimates you…

Estimate is but one part. The other is planning for obstacles and changes, i.e. have escalation paths and responsibilities in place:

Clear procedures to remove impediments, decision makers in the loop to ok scope/feature changes, resourcing agreed upfront, user engagement for testing locked-down, senior leadership aligned and kept informed regularly. Someone running the administrative side of the project, keeping people on target, etc. (could be a double hat, of course).

Sounds all rather "menial", but high degrees of organization really make a difference in delivery on larger projects.

Re: Planning and estimating large-scale software projects

#45

Post by pphysch » Wed, Jul 21, 2021, 5:47 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 :)

What tools and methods do you use for creating, sharing, and modifying project charts?

Re: Planning and estimating large-scale software projects

#46

Post by kalleth » Wed, Jul 21, 2021, 5:49 PM UTC

mzarate06 wrote: post #43

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

I'm curious that you mention project management courses from university . How much benefit have you found them to provide in practice? Asking b/c I've taken two courses in dev process or project management in my academic career, and neither provided substantial value or benefit to how I've lead projects professionally.

In the early stages of my career, or in startup life? Absolutely not. Very little relevance; XP/SCRUM were both covered together in a single 50 minute lecture, the rest of the PM aspects were tackling paperwork-generation methodologies like the "Rational Unified Process" and "Dynamic Systems Development Model", both of which I feel like would be _hell_ if I actually had to work within.

However, there were techniques (like critical path analysis) that as I've got more senior, started working at larger companies, and started stepping down the senior leadership path, I've started to see some applicability to. Not direct applications - they still need taking with a massive pinch of salt, and modifying for modern learnings in industry, but they do start to provide some value, even if it's just learning what the grey-hairs in the exec are used to seeing :)

Re: Planning and estimating large-scale software projects

#47

Post by kalleth » Wed, Jul 21, 2021, 5:51 PM UTC

pphysch wrote: post #45

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

What tools and methods do you use for creating, sharing, and modifying project charts?

Depends how much of a perfectionist I'm feeling. For the initial development, a sharpie, index cards, and a whiteboard wall - or Lucidchart, because it's basically an in-browser whiteboard/drawing tool.

Once the project is ongoing and you'll need to account for changes, I've either done it manually (which takes an age) or handed it off to PM's to oversee using either MS Project, airtable with a custom-authored set of actions/etc, or PrimaVera.

Re: Planning and estimating large-scale software projects

#48

Post by killjoywashere » Wed, Jul 21, 2021, 5:53 PM UTC

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…

A Jira plug-in to use some sort of Bayesian system to adjust developer priors at the task and sprint level. That would be amazing.

Re: Planning and estimating large-scale software projects

#49

Post by crooked-v » Wed, Jul 21, 2021, 5:57 PM UTC

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…

I'm reminded of the classic saying: "The first 95% of the work takes 95% of the time, and the last 5% of the work takes the other 95% of the time."

Re: Planning and estimating large-scale software projects

#50

Post by mason55 » Wed, Jul 21, 2021, 5:59 PM UTC

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…

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 they actually will get it done.

The key is backing it up continually and really not getting mad about estimates that are longer than I’d like. And, for people who I do think are sandbagging, asking more specific questions about the details of the estimate in a non-combative way.

And of course some people really are bad at estimating. But I find if they don’t improve with coaching then it’s a symptom of a bigger problem (not thinking things through all the way) which manifests in other ways beyond estimation (eg poor design)