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

Re: Planning and estimating large-scale software projects

#51

Post by rabuse » Wed, Jul 21, 2021, 6:00 PM UTC

z3t4 wrote: post #5

hnbad wrote: post #3

I have to admit I popped a monocle when I saw the estimate for what is described as a rudimentary ecommerce website without even basic features like authentication and payment come down to 43 team-weeks, or in other words 12,040 team-hours. Even at one person per team being billed as $20/hr this works out to almost a quarter million dollars. I understand the numbers are given as an example but I think the problem is…

The thing with software is that it takes two weeks to get to 90% finished, then two years to get from 90% to something 100% production ready. Having worked over 5 years with ecommerce software I could write a fully working e-commerce site in two weeks, but then the marketing teem want to have it all integrated with 50 different tracking systems, and support 10 different payment systems in 30 countries, and have the c…

This has been the case for almost every project I've worked on. It starts out as super simple, and then the edge cases roll in, and then the feature creep, and then the bugs start piling up, and now it's been years on a "just a couple months" estimation.

Re: Planning and estimating large-scale software projects

#52

Post by msluyter » Wed, Jul 21, 2021, 6:07 PM UTC

killjoywashere wrote: post #48

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.

Yeah I've always felt like the missing part of the loop (in the context of pointing stories) is looking at point estimates and then tracking how accurate they were, _by developer_. E.g., I throw 2 points, but it turns out the story takes something along the lines of 13 points, then my estimation was pretty low and my personal "estimation multiplier" is increased. Subsequently, actual point estimations could take the estimation multiplier into effect.

Of course, this is mostly a toy idea that's fun to think about, but seems pretty untenable given that it requires keeping track of time, which most developers hate. That, and there'd no doubt be incentive to game the system by padding estimates or other shenanigans.

Re: Planning and estimating large-scale software projects

#53

Post by andruby » Wed, Jul 21, 2021, 6:08 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…

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.

Re: Planning and estimating large-scale software projects

#54

Post by ColinHayhurst » Wed, Jul 21, 2021, 6:27 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.

Fair enough. It was the word that came to mind and I might have used a better one. Important doesn't quite capture it. Time is invariably the most precious resource, so perhaps "crucial".

Re: Planning and estimating large-scale software projects

#55

Post by satyrnein » Wed, Jul 21, 2021, 6:28 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…

Joel Spolsky's team actually built that approach into a feature: https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

Re: Planning and estimating large-scale software projects

#56

Post by AnimalMuppet » Wed, Jul 21, 2021, 6:31 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…

Yeah. I'm a big fan of making the person who made the promise fix the mess. You dreamed up something and promised it to the customer? You get to go back to the customer and eat the crow. Maybe that will teach you not to do it next time.

Anything else is just enabling (or even rewarding) bad behavior. If you do, expect to get more of it.

Note well: I have never been a manager, especially not an upper-level manager over both sales and engineering. I don't know how well my recommendation will fly in the real world. (Hey, I guess that makes me the guy who just sold something without knowing if it can work...)

Re: Planning and estimating large-scale software projects

#57

Post by commandlinefan » Wed, Jul 21, 2021, 6:38 PM UTC

mason55 wrote: post #50

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…

> 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" estimate (in part because too many things were rushed in the beginning to try to meet "the date"), but nobody will ever compare the final outcome against the original estimate anyway... because estimates are never meaningful.

Re: Planning and estimating large-scale software projects

#58

Post by pphysch » Wed, Jul 21, 2021, 6:41 PM UTC

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 leadership. However, social factors (the real people involved with the project) are an integral part of actually getting anything done, so I agree with the author's premise that the whole process should be viewed holistically (and ideally run by one technologist).

Re: Planning and estimating large-scale software projects

#59

Post by rmah » Wed, Jul 21, 2021, 6:41 PM UTC

mdtusz wrote: post #13

dboreham wrote: post #6

Earlier quoted context omitted.

Instead, we as an industry prefer to adopt magical thinking where we pretend that software projects aren't hard and lengthy and risky (even when the domain and tech are well understood), then we act surprised when the project "overruns".

This is extremely difficult to convey to non-developers though because they often look at software as a house and think "there's tons of houses (ecommerce sites) built every day and it's down to a science - how hard can a house (ecommerce site) really be", but miss out on the fact that all houses have pretty much the same structure of a foundation, framing, wiring and plumbing, and a covering of paint and a roof - th…

Then this is, IMO, a problem with the software developers (in the broadest sense, not just programmers). Most e-commerce in fact, DO share the same framing, wiring and plumbing as all the others. This is why you can buy an e-commerce package off-the-shelf and customize it.

If the business is a relatively generic e-commerce store, it should usually not be building bespoke e-commerce software. Unless, of course, there is some technology feature that will be your competitive advantage/differentiator. But let's be honest, that's pretty damn rare in the space of e-commerce stores.

Re: Planning and estimating large-scale software projects

#60

Post by commandlinefan » Wed, Jul 21, 2021, 6: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,…

> CAN be reasoned with

Sort of. What you really end up doing is making enemies and burning bridges to defend a software estimate that ends up being completely unrealistic anyway. Sure you can "win" an argument with a "stakeholder" if you fight hard enough, but you'll pay for it later. They want to hear what they want to hear.