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

121–130 of 138 posts

Re: Planning and estimating large-scale software projects

#121

Post by mtippett »

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…

Arggh.

I hate multipliers. It's not poor estimates that need to be doubled. It's the lack of experience in identifying the complexity or likely risks in a project.

So rather than multiply, ask for risks. You'll find that most engineers know the risks (or at least they may know it is without risk). As you explore risks, you'll find the estimates will lengthen automatically.

So rather than do the multiplier, explore the risks. They are what makes projects late, not intrinsic engineer productivity. You'll end up with better engineers who know themselves and their problem spaces better. You'll also get a clearer view of what could screw up your project.

Re: Planning and estimating large-scale software projects

#122

Post by mtippett »

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

I don't trust multipliers. I often find those rules of thumb to be very poor predictors. Since if you don't know how can you predict some fixed fraction of the work? I led a small team to deliver software over a multi-year project. The software was used to control a machine. The machine was contracted as part of a multi-million dollar deal. We delivered software on time and with good quality. It was very far from tri…

Yay #noestimatemultipliers

Re: Planning and estimating large-scale software projects

#123

Post by mtippett »

kalleth wrote: post #46
mzarate06 wrote: post #43

Earlier quoted context omitted.

I'm curious that you mention project management courses from university . How much benefit have you found them to provide in practice? Asking b/c I've taken two courses in dev process or project management in my academic career, and neither provided substantial value or benefit to how I've lead projects professionally.

In the early stages of my career, or in startup life? Absolutely not. Very little relevance; XP/SCRUM were both covered together in a single 50 minute lecture, the rest of the PM aspects were tackling paperwork-generation methodologies like the "Rational Unified Process" and "Dynamic Systems Development Model", both of which I feel like would be _hell_ if I actually had to work within. However, there were techniques…

Fully agree. There are huge nuggets of wisdom in old-school engineering. For example PERT is something that most people don't know about. But it's simple to apply in the real world. Get three estimates - optimistic, pessimistic and realistic. double the realistic, add the optimistic and pessimistic and divide by four. It's basically a centerweighted estimate - but it forces you to think about the the corner-cases and what could go wrong.

Lots of other old school stuff that we "just turning grey" people need to translate for the new kids.

Re: Planning and estimating large-scale software projects

#124

Post by nudgeee »

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

Arggh. I hate multipliers. It's not poor estimates that need to be doubled. It's the lack of experience in identifying the complexity or likely risks in a project. So rather than multiply, ask for risks. You'll find that most engineers know the risks (or at least they may know it is without risk). As you explore risks, you'll find the estimates will lengthen automatically. So rather than do the multiplier, explore th…

I agree that project risks should be explored and multipliers are not substitutes for them. However multipliers are useful for ongoing dynamic distractions outside of the project that reduce your productivity, for example company meetings, hiring/debriefs, getting pulled into critical bugs, helping to support colleagues, etc.

Re: Planning and estimating large-scale software projects

#125

Post by feoren »

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

Arggh. I hate multipliers. It's not poor estimates that need to be doubled. It's the lack of experience in identifying the complexity or likely risks in a project. So rather than multiply, ask for risks. You'll find that most engineers know the risks (or at least they may know it is without risk). As you explore risks, you'll find the estimates will lengthen automatically. So rather than do the multiplier, explore th…

I don't think OP is saying one engineer is 3x "more productive"; rather they're saying that engineers tend to be consistent in how much they over- or under-estimate tasks. It sounds a little like "story points", where each developer may end up having their own estimation scale.

Re: Planning and estimating large-scale software projects

#126

Post by hnbad »

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…

Sure but the article was about a linear process with the final product being understood to be an MVP, so the remaining 10% (which really feel more like Zeno's arrow, i.e. the sooner you get to 100% the closer the time necessary to complete the remaining work approaches infinity) won't be part of the calculation and the 90% solution is the first "definition of done".

The article clearly points out discount codes as an example for a feature that could be moved out of the initial spec. And the spec itself is clearly missing various features necessary for the app to be even remotely usable.

Re: Planning and estimating large-scale software projects

#127

Post by gadders »

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…

A project plan is only a point in time prediction of a project end date. It should be continuously updated as new facts are known (scope changes, additional complexity, unknown risks happen).

Obviously as you progress through your project, you predicted end date should become more and more accurate.

A project plan, though, is a prediction of the future. I've not seen anyone that can predict the future perfectly. That's not to say that you shouldn't do it, but defective project management creates a project plan on Day 0 and then tries to bend reality to meet the plan.

*Obviously all the above is caveated with reasonableness - you do try and bend reality a certain amount to meet your plan, and you try and keep to your plan as much as possible.

Re: Planning and estimating large-scale software projects

#128

Post by xcambar »

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

Good management advice. I was a first-line manager for a Japanese company ( hard estimates, with lots of international frowny-faces, if the estimate was missed). That was pretty much what I did. We usually came relatively close to our estimates, but would sometimes encounter anomalous situations that would force us to re-evaluate. I found that my managers were pretty good at accepting these, as long as they were not…

Honest question: how do you function in a team?

I know a bunch of very self-aware devs, but they almost all have a very double-edged relationship with team work: theylove to learn and share yet see other people as impediments or risks on their way to delivery.

How to improve on these situations?

Re: Planning and estimating large-scale software projects

#129

Post by ChrisMarshallNY »

xcambar wrote: post #128
ChrisMarshallNY wrote: post #94

Earlier quoted context omitted.

Good management advice. I was a first-line manager for a Japanese company ( hard estimates, with lots of international frowny-faces, if the estimate was missed). That was pretty much what I did. We usually came relatively close to our estimates, but would sometimes encounter anomalous situations that would force us to re-evaluate. I found that my managers were pretty good at accepting these, as long as they were not…

Honest question: how do you function in a team? I know a bunch of very self-aware devs, but they almost all have a very double-edged relationship with team work: theylove to learn and share yet see other people as impediments or risks on their way to delivery. How to improve on these situations?

Very well. You don’t last long in a Japanese company, if you don’t “team” well.

I lasted for almost 27 years.

I’m working on a team, now. I am doing the native app development, and I was the original author of a couple of the servers, but there’s a relatively young chap, working on another server (we’re up to 3 servers). He has some experience, but nowhere near mine. I’ve learned to work with a light touch, in these circumstances. I demand a lot, from myself, and expect his work to meet my bar -but only at the API level. I stay out of his kitchen. I make sure that he has no problem, asking me any questions, or for help.

When he asks for help, I immediately provide it, with no judgment. In turn, he has introduced me to a couple of new tools and techniques that I have adopted.

Here's an example:

Before this project, I'd never used Postman. I used much simpler REST explorers. You'd probably laugh at the primitive tools I used, when developing my servers.

I suspect that you wouldn't laugh at the results, though.

He asked if I could use Postman to give him examples of using the API for one of the servers that I wrote.

I could have been a dick, and said "RTFM" (It's a very well-documented API). Instead, I learned Postman. Didn't take long. He's thrilled at the results. Our exchanges seldom take more than a couple of Slack messages and a Postman query example.

I now have experience using Postman, and will have a new tool at my disposal, for working with others. It probably won't be a regular part of my solo work (Insisting on using team tools for solo work can be a bit problematic), but it's nice for teams.

I am encouraging him to learn Charles Proxy. He's not really following up on that. It's not the end of the world, but he's missing out on some really awesome inspection capabilities by ignoring the tool (and it means that I have to be a bit more creative with my Postman examples). It may cause problems down the road, and I'll deal with them, if they crop up. I will do so in a non-judgmental way. Our relationship is valuable, and needs to be treated with respect. I treat him with respect, and he does the same for me.

In my world, that’s how we team.

Re: Planning and estimating large-scale software projects

#130

Post by hu3 »

kalleth wrote: post #92
justin_oaks wrote: post #85

Earlier quoted context omitted.

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.

This is where the ideal meets the annoying reality of The Enterprise (tm). I can't talk in too much detail, but in general, the deadline date was fixed through commercial contracts signed at a high enough level that engineering didn't have sight of them. The concept and commercial case was sound, but the implementation hadn't been worked out yet, when a date was set. My strong preference would be for estimation to co…

I had this "Enterprise sets the deadlines" experience just yesterday.

I delivered a spreadsheet with detailed information of how long it would take to develop each feature of the new module they wanted. It totalled around 3 months of development.

Fancy suit folks told me 3 months wouldn't do because sales promised it would be ready in 2 months. Then I was asked where could shortcuts be taken.

In the end we had to cut features that will certainly upset our client given their initial expectation.

Post reply on HN