Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Planning and estimating large-scale software projects

tomrussell.co.uk

Post reply on HN
Print view View original

11–20 of 138 posts

Re: Planning and estimating large-scale software projects

#11

Post by kalleth »

commandlinefan wrote: post #9
kalleth wrote: post #4

Earlier quoted context omitted.

I think I would have popped a monocle too, had that been the real example and estimate from a team! I tried to think up an accessible example that didn't require too much context on the part of the reader, so obviously, as you correctly point out, all the numbers are made up, and I'm trying to use it solely to demonstrate the workflow :)

> all the numbers are made up Well... have you actually applied this process successfully? If so, wouldn't you have some actual numbers to point to from a past project? Names and details changed a bit to protect the innocent, of course.

I have, yes - or I'd feel a bit like a charlatan writing about it!

The problem with the real world examples is the business domain, which was hyper complex and the specific "pieces" of work I described wouldn't have been easy to grasp for most not familiar with the esoteric side of fintech that the project took place in.

So I went with a simpler, albeit contrived and more accessible example.

Re: Planning and estimating large-scale software projects

#12

Post by hnbad »

dboreham wrote: post #6
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…

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

I'm not saying that this isn't a good estimate for "doing it properly". I'm just saying that no client will let me bill half a million dollars and spend the better part of a year to build them a bare bones ecommerce website from scratch that doesn't even have invoicing or an admin interface.

I'm mostly just saying if the author is able to sell what amounts to half a broken Woocommerce installation for half a million dollars (assuming it's at least a team of two billed at $20/hr), I must be in the wrong market.

Re: Planning and estimating large-scale software projects

#13

Post by mdtusz »

dboreham wrote: post #6
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…

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 - this is largely kept consistent and we'll implemented by building codes.

I can only speak from my own experience, but every single web application I've worked on has had a wildly different structure than the others and the only consistent thing between them has been endpoint routing mechanisms.

Re: Planning and estimating large-scale software projects

#14

Post by antondd »

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 between the Myers-Briggs personality test and modern day astrology.

Re: Planning and estimating large-scale software projects

#15

Post by commandlinefan »

kalleth wrote: post #11
commandlinefan wrote: post #9

Earlier quoted context omitted.

> all the numbers are made up Well... have you actually applied this process successfully? If so, wouldn't you have some actual numbers to point to from a past project? Names and details changed a bit to protect the innocent, of course.

I have, yes - or I'd feel a bit like a charlatan writing about it! The problem with the real world examples is the business domain, which was hyper complex and the specific "pieces" of work I described wouldn't have been easy to grasp for most not familiar with the esoteric side of fintech that the project took place in. So I went with a simpler, albeit contrived and more accessible example.

Were they monocle-popping results?

Re: Planning and estimating large-scale software projects

#16

Post by christophergs »

Great post. A key point you don't bring up is the aftermath, even if you do deliver. Especially in non-tech companies there still remains the tendency to view these projects as "done" after the end of the project/MVP etc., with no understanding that sites need ongoing maintenance and improvements. And that this work is still considerable.

Re: Planning and estimating large-scale software projects

#18

Post by gonzo41 »

christophergs wrote: post #16

Great post. A key point you don't bring up is the aftermath, even if you do deliver. Especially in non-tech companies there still remains the tendency to view these projects as "done" after the end of the project/MVP etc., with no understanding that sites need ongoing maintenance and improvements. And that this work is still considerable.

That reminds me of that scene in the series Chernobyl where the main scientist briefs everyone on the cleanup effort and ends with something like "The first battle is won and now begins the long war" with everyone being suitably cold in their response.

I get the same response sometimes when I talk about the long tail of maintenance at work.

Re: Planning and estimating large-scale software projects

#19

Post by kalleth »

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 industry discovers how to improve overall project management techniques, I don't see why we'd consider our industry "above" them.

Re: Planning and estimating large-scale software projects

#20

Post by noptd »

christophergs wrote: post #16

Great post. A key point you don't bring up is the aftermath, even if you do deliver. Especially in non-tech companies there still remains the tendency to view these projects as "done" after the end of the project/MVP etc., with no understanding that sites need ongoing maintenance and improvements. And that this work is still considerable.

Agreed, especially for MVPs and "phase 1" projects.

At my current company, it's reached a point where we flat out reject product proposals for features or changes that would need to be hacked together for an MVP without a time commitment from all necessary stakeholders on how it will properly be implemented for phase two (iff phase one is a success). It's amazing how quickly "critical" features become irrelevant to product when they understand even half the amount of work required to properly implement them.

Post reply on HN