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

81–90 of 138 posts

Re: Planning and estimating large-scale software projects

#81

Post by setr »

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…

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 because it would take too long or be too expensive, without first asking how much time/cost can be consumed

The same occurs with estimating — they’ll give a risky estimate instead of a safe one, because they’ll unilaterally decide the stable one is unacceptable; and not bother mentioning this with their estimate, or knowing what the rest of the timelines look like.

The other half of the problem is that people tend to only want to give one number (and people typically ask for a single number), but what you really want for project planning is the median +- margin of error timelines. The 1x,2x,3x rule is just a hack to work around that unwillingness.

Re: Planning and estimating large-scale software projects

#83

Post by mason55 »

commandlinefan wrote: post #68
stingraycharles wrote: post #62

Earlier quoted context omitted.

I think this attitude is too fatalistic. A good approach would be to see if there’s some way to break up the feature in smaller pieces, into smaller milestones, etc. If you have a manager that is unable to deal with this kind of stuff, then your problem is the manager, not the estimates. Estimates are extremely useful, and you’re doing yourself a disfavor if you think that they are never meaningful.

If I was surrounded by people who could put together accurate software estimates that made upper management happy, and I was the only one who was always got it wrong, I'd hang up my hat and see if I could get a job selling life insurance. Hell, if 10% of my peers could put together accurate software estimates that made upper management happy, I'd lobby to have them elevated to senior positions and spend all my time b…

> because the people asking for the estimates don't actually know what the goals are

And this is the real problem. People who know how to build & design products should be able to explain the goals of what they're asking for. If they don't then either you need to move or you need to get them moved.

One of the first things I tell new engineering managers is that an easy hack to is to always be asking yourself "what am I trying to accomplish?" Whether it's an emotional conversation or writing a document, if you can't answer that question then you probably shouldn't be moving forward with whatever you're about to do. And if you're writing a document, make the very first section "The goal of this document is..." because as you write you can constantly ask yourself "is what I'm writing accomplishing my stated goal?"

Communicating your goal also helps your team - if they know the goal then they don't act as automatons following directions, they can make actual decisions on their own.

If you know the business goal of what you're building then you have a better shot at getting the requirements and tasks correct, which gives you a better shot at giving a good estimate. I've worked with a number of product managers who had no real goal behind what they were asking for. I refuse to have the team start building things until someone can explain why we're doing it and what we're trying to achieve.

Re: Planning and estimating large-scale software projects

#84

Post by eikenberry »

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…

Did you ever come across a person who was If the answer is never or rarely then that lends a reasonable amount of credence to the idea of just multiplying your estimates. Because you most likely should and the chance of overestimating is low.

Re: Planning and estimating large-scale software projects

#85

Post by justin_oaks »

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

How are deadline dates assigned? Is the deadline exactly the same as the estimated completion date?

Realistic estimates aren't padded, but they still have significant probability of being inaccurate. After all, they're estimates, not information from the future transmitted to the past.

Re: Planning and estimating large-scale software projects

#86

Post by ed312 »

sarks_nz wrote: post #82

How to make developers want to hit their deadlines with quality? Startup land. There was no feedback loop that rewarded developers to meet the estimates. Stock options weren't an option, and I didn't want them to do a sloppy job just to hit the 'deadline'.

Bonus and/or equity grants via review feedback are a blunt but effective tool. You could probably reduce this to "My team is not highly engaged/motivated, and I think it would better meet my company's needs if they were. How can I improve that?"

Re: Planning and estimating large-scale software projects

#87

Post by PUSH_AX »

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

Our paths crossed on the engineering team of a certain letterbox flower company, for a short time at least. Good to see you doing well Tom, nice article.

Re: Planning and estimating large-scale software projects

#88

Post by mason55 »

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…

Yeah, from the product management side this is the way to approach it. Make priorities clear and make it clear whether the important part is the date or some set of features.

If the date is what's important then start the conversation with "here's the date, can we get this all done by then? If not then what can we get done? If we can't do it all, here's the stuff that I think is important." And make sure to allow some time for people to think about things and give an honest estimate.

If the features are what's important then don't even put a real estimate on it because then that just turns into features + date which never works well. SWAG it by weeks or months and refine as you get further along.

It's basically a law that we always want t do more than we have time for, so it's important for the decision maker to be clear about which parts really matter.

Re: Planning and estimating large-scale software projects

#89

Post by kalleth »

PUSH_AX wrote: post #87
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 :)

Our paths crossed on the engineering team of a certain letterbox flower company, for a short time at least. Good to see you doing well Tom, nice article.

Thanks! And I couldn't possibly comment on which company that could be...

Hope you're doing well too!

Re: Planning and estimating large-scale software projects

#90

Post by galaxyLogic »

Doesn't this assume you have the "spec" before you start implementing it? But then how do you estimate how long it will take to come up with that spec?

If you have a very good detailed spec you have already done much of to work to make the implementation easy.

If the spec is high-level and "fuzzy" it leaves the work of "resolving the spec" to the programmer.

So trying to estimate the time it takes to code a system depends on the quality of the spec, and therefore is difficult if there is no standard on how detailed the spec is to be.

Post reply on HN