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

131–138 of 138 posts

Re: Planning and estimating large-scale software projects

#131

Post by tonyedgecombe »

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…

I've seen some managers who like to turn your estimates into a stick they can beat you with. They can never be satisfied.

Re: Planning and estimating large-scale software projects

#132

Post by mattcwilson »

sarks_nz wrote: post #97
skohan wrote: post #95

Earlier quoted context omitted.

Honestly it's not developers' job to hit their estimates. If we're talking about a long-term estimate, as in "this project will be finished in 6 months", it's your job in management to find a way to do this. You've got to break the goal down into achievable sub-goals, and monitor progress along the way. Long term estimates will be wrong. Software projects generally take longer than expected, so it's up to you as a ma…

Thanks for that. I'm talking about the difference between hitting the deadline on Monday versus Friday. How to incentivise that? ie, do half an hour more work for a week, or skip the table-tennis when someone asks, etc. As a developer, I was into making sure I hit my goals, and at work to work. As a manager I do struggle with how to emphasise that ownership of product, quality, time. Why should developers care about…

I think you might want to ask yourself: why do you want this? Do you think it will benefit them somehow? How? Are you orienting around results you care about, or around results they care about?

Re: Planning and estimating large-scale software projects

#133

Post by epalm »

noptd wrote: post #20
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 p…

Knowing when to say ‘No’ is an important (and probably underrated) skill.

Re: Planning and estimating large-scale software projects

#134

Post by lazyasciiart »

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

My rule of thumb is that if you give me an honest estimate, then it’s my job to make it work. Negotiate scope, change implementation, move resources, increase cost, whatever. But I need estimates that at least reasonably correspond to reality in order to make my case successfully. The biggest issue I have is developers making business decisions without realizing it or without saying it — saying no to something becaus…

The biggest issue I've seen is developers making business decisions knowingly, but without saying it to the business people. I was on a team that literally sat around saying "if we tell them it will take 18 months to do this then they'll just cancel it, but we want to do it, so let's say 6 months and then we'll just be late but they never cancel stuff in progress". I quit that team for many reasons, but they got started under that 6 month estimate and four years later the project is still going.

Re: Planning and estimating large-scale software projects

#135

Post by Pokepokalypse »

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 found that it's important to show your work - don't just cough up a number, show them your disciplined process at how you arrived at that number, (and I use PERT, as a process, and it's rarely steered me wrong).

As an engineer, it's my job to give an estimate. It's my boss' job to figure out whether that can work within his budget or if the task can be re-scoped. But I have to give him a number he knows is legitimate, and not some half assed BS I pulled out of my ass.

At a recent job, I witnessed an engineering team use some kind of agile "planning poker" game to arrive at estimates. Everyone on the team thought this was a great method. Yet they consistently failed to hit their targets, and it had a very profound impact on the performance of the ENTIRE company, (where various teams had serious backlog-coupling issues).

Because I'm a devops engineer (despite previously having been a development lead at a different company - which was a Fortune 500 by the way) and therefore, not considered a "real programmer" - of course I wasn't taken seriously when I tried to advocate a more data-driven, disciplined approach. But what do I know.

Re: Planning and estimating large-scale software projects

#138

Post by phist_mcgee »

HillRat wrote: post #109
satyrnein wrote: post #55

Earlier quoted context omitted.

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

Fogbugz really was (is!) an underappreciated product. Jira’s become a necessary evil, but I really wish FB had managed to make a bigger dent in the market.

Something about the letter 'z' always screams out to me as a forgotten marker of 90s-00s culture. Really, any substitution for the letter 's' these days feels almost _antiquated_.
Post reply on HN