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

21–30 of 138 posts

Re: Planning and estimating large-scale software projects

#21

Post by christophergs »

gonzo41 wrote: post #18
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.

Haha, love that show. There's definitely a parody in there somewhere

> Now that I know what software estimation is, I no longer need you.

Re: Planning and estimating large-scale software projects

#22

Post by ngrilly »

> It also tells us how many team-weeks this fictional, idealised project would require [...] by adding all the estimates together.

I would be wary with just "adding all the estimates together". That's because we tend to estimate the median or the mode of the task duration, and not the average. Means can be added together, but not medians.

Re: Planning and estimating large-scale software projects

#23

Post by dls2016 »

Project management is hard. I wrote and won an SBIR award this year. A much different scale than the article, but I spent a lot of time writing the plan and budget and sourcing components and estimating software tasks. Two months in and a big chunk of that is out the window… haha. Finding connectors and other components has been a big source of pain, especially if purchasing in small quantities. Another example: I bought a consumable product which then immediately became unavailable… so do I try to make do with what I have on hand or make the decision to switch to a replacement?

Stressful, but I try to have fun. And extremely satisfying when things work out!

Re: Planning and estimating large-scale software projects

#25

Post by henning »

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. If it is, then they are also just guessing.

Re: Planning and estimating large-scale software projects

#26

Post by tonyedgecombe »

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…

You can't really do that with the Olympics though as there is a hard deadline. Once you have a fixed date then either quality or cost are going to have to give.

Re: Planning and estimating large-scale software projects

#27

Post by marcus_holmes »

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…

> instead make it ongoing OpEx

Every non-tech startup founder who's approached me with "how long will it take to build an MVP for my startup idea?", I've answered with this. Development is an ongoing cost, a process, not a once-off capex cost.

I recommend to them going the other way. Start with "how much can you afford to pay a dev team sustainably?" then work out how many devs that works out to, then work out how long your MVP will take to build based on their estimates (and estimates are not deadlines).

Not quite the same as #no_estimates (which I also try to argue for whenever possible), but close.

Re: Planning and estimating large-scale software projects

#28

Post by marcus_holmes »

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

> I popped a monocle This is why I don't bother with estimates any more - not because I think it's impossible, or even necessarily too hard, but because I've observed (consistently over a 30 year career) that it's pointless. Even if you could estimate with perfect precision exactly how long a software task was going to take, they would just push back, say, "that's too long" and argue with you until you told them what…

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.

Around this point the penny finally dropped that software estimation is a political process, not a technical process.

Re: Planning and estimating large-scale software projects

#29

Post by kalleth »

marcus_holmes wrote: post #28
commandlinefan wrote: post #7

Earlier quoted context omitted.

> I popped a monocle This is why I don't bother with estimates any more - not because I think it's impossible, or even necessarily too hard, but because I've observed (consistently over a 30 year career) that it's pointless. Even if you could estimate with perfect precision exactly how long a software task was going to take, they would just push back, say, "that's too long" and argue with you until you told them what…

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…

That's really tough, and I'm sorry you had to deal with it.

I was lucky in that I was dealing (in both cases where I've run similar flows to this) with above-board exec teams who wanted the best quality information I could give them - even assuming that estimates are just assumptions - even if it meant having some tough conversations about scope or headcount.

Re: Planning and estimating large-scale software projects

#30

Post by NikolaNovak »

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

I think author addressed that explicitly as valid and true software engineer perspective, right at beginning of the article; and explained that such software engineers, and products they build, then usually slot into larger company's ecosystem (as by strict math, most IT team members will work at a large company as opposed to a startup), full of people and leaders and departments and teams and project who have plans and deadlines and dependencies, which are also valid and true.

I've had either luck or misfortune to "flip a switch" from two decades of being a techie/architect, to being a mid-manager, on basically a specific date as opposed to over the years, due to project's needs; and it's like that B&W picture of two faces and one vase in middle. Both perspectives are true, even if opposing and contradictory.

Good business lead will understand software engineer's perspective - even if it's not their primary view of the world, they can squint and catch a glimpse as needed. Likewise for good software leads.

Obstinate unwillingness to see or ascribe merit to other perspectives puts a ceiling on everybody's progress.

Post reply on HN