Page 1 of 1

Estimate the length of time to complete a project

Posted: April 20th, 2017, 8:41 pm
by CommodityQuant
I am a quant dev with a big C++ quant project and am charged with estimating how long it will take me to deliver. I have 3 days to produce the estimate.
I think that tentatively, management expect me to give a figure around the three months mark.
This project involves enhancing legacy code.
Can anyone give any guidance to resources on how to produce an estimate?  Of course, it's notoriously difficult to tell when a several-months project can be delivered.  It must be a common problem, and I'm sure there's a fair amount of literature on project
estimation but it would be good to see resources that are specifically oriented towards C++ quant projects rather than the completely
general case.
One thing that might be helpful might be info about how long various quantlib enhancements took.  This library is more similar to
quantlib than any other readily available library.  Any thoughts?  Thanks a lot.

CommodityQuant

Re: Estimate the length of time to complete a project

Posted: April 21st, 2017, 9:56 pm
by snufkin
The ultimate guide to estimates like that is given by Joel Spolsky at https://www.joelonsoftware.com/2007/10/ ... cheduling/; the previous version, though he says it's obsolete, is what you want to see: https://www.joelonsoftware.com/2000/03/ ... schedules/

In brief, you spend a day splitting the project into tasks, preferably under a day each. Then (another day), you assign an effort estimate to each one and sum those up. Then you spend a day considering the presentation of the estimate. There's absolutely nothing specific about C++ or quant case, it's just that the tasks will be different.  

Having said all that, consider what you lose if the estimate you give is one year? Two years? One month? Six months? In a sense, that's more of an exercise in setting up expectations. If you have an expectation of three months, do you need to challenge it? Are you okay with shipping something that's a result of three months worth of work, and claiming that's what's expected?

Re: Estimate the length of time to complete a project

Posted: April 22nd, 2017, 7:07 am
by CommodityQuant
snufkin, Many thanks for some very useful ideas and reference.

CommodityQuant

Re: Estimate the length of time to complete a project

Posted: April 22nd, 2017, 7:54 am
by ppauper
I'm guessing that if you estimate 3 months and it takes 4, it looks like you have mismanaged the project, but if you estimate 6 months and it takes 4, you're a hero for bringing it in early
As snufkin said, managing expectations.

Re: Estimate the length of time to complete a project

Posted: May 18th, 2017, 3:10 pm
by DominicConnor
Timescales are important, but also the schedule and expectations you set...

I've long advocated  "Continuous Visible Productivity", in other words structuring your work so that management regularly get to see progress. Big deep dives where nothing seems to happen are bad for your survival and bonus.

I'd also counsel you to run http://www.gimpel.com/html/index.htm PC Lint.
It will give a long list of bugs, potential bugs and general shit. This is important because you're dealing with old code. This is a thing to show to management to let them know how much grind ther is in the task. They won't read it,. but it sets an agenda...
Most of debugging is finding the bug, fixzing is easier usually. That means you have a list of defects that you can tick off and show progress, even better, this isn't just for show, you are genuinely makling things better.

Re: Estimate the length of time to complete a project

Posted: May 20th, 2017, 7:56 pm
by ISayMoo
The ultimate guide to estimates like that is given by Joel Spolsky at https://www.joelonsoftware.com/2007/10/ ... cheduling/; the previous version, though he says it's obsolete, is what you want to see: https://www.joelonsoftware.com/2000/03/ ... schedules/

In brief, you spend a day splitting the project into tasks, preferably under a day each. Then (another day), you assign an effort estimate to each one and sum those up. 
And then you multiply the estimate by x >= 1.5.

Re: Estimate the length of time to complete a project

Posted: June 1st, 2017, 9:03 am
by Cuchulainn
With estimation it is always junk in junk out. So if you cannot estimate ask for a prototype project to get a feel for the complexity.
Developers love to please, so they always forget pre and postprocessing in their estimates.

I have found 3-point estimation to be useful, especially for binding fixed price projects

https://en.wikipedia.org/wiki/Three-point_estimation

Re: Estimate the length of time to complete a project

Posted: June 1st, 2017, 9:10 am
by Cuchulainn
One thing that might be helpful might be info about how long various quantlib enhancements took.  This library is more similar to quantlib than any other readily available library.  Any thoughts? 

Can you give some use cases, features used, documentation(yes), OOP, templates, design patterns, inheritance etc.

Do you have design blueprints or do you have to wade in code to do reverse engineering? Do you have a good understanding of the current system?

It is not far-fetched but one can spend 4.5 days per week just 'thinking' about the ramifications of adding a new feature and .5 days coding up.

Project estimation time increases exponentially IMO when

1. Deep inheritance class libraries; many classes down the tree are semantically incorrect.
2. Multiple inheritance
3. No blueprints
4. Undocumented design patterns
5. Wrong pattern(Observer, Singleton)
6. Over-engineering

Are we in the era "OOP legacy software revisited".

Re: Estimate the length of time to complete a project

Posted: June 1st, 2017, 9:30 am
by Cuchulainn
The ultimate guide to estimates like that is given by Joel Spolsky at https://www.joelonsoftware.com/2007/10/ ... cheduling/; the previous version, though he says it's obsolete, is what you want to see: https://www.joelonsoftware.com/2000/03/ ... schedules/

In brief, you spend a day splitting the project into tasks, preferably under a day each. Then (another day), you assign an effort estimate to each one and sum those up. Then you spend a day considering the presentation of the estimate. There's absolutely nothing specific about C++ or quant case, it's just that the tasks will be different.  

Having said all that, consider what you lose if the estimate you give is one year? Two years? One month? Six months? In a sense, that's more of an exercise in setting up expectations. If you have an expectation of three months, do you need to challenge it? Are you okay with shipping something that's a result of three months worth of work, and claiming that's what's expected?
hmmm.. very sweeping statements
Personally, Barry Boehm's book on Software Economics and Ed Yourdon's Deathmarch add some needed gravitas.

Re: Estimate the length of time to complete a project

Posted: July 5th, 2017, 1:31 pm
by rmax
Late to the party on this one. Agree with much of what is said above. What I think really helps with any form of estimate is treat it as a market and make a two way price. What price would you make if it was 1 USD a day above or below you price. The spread tends to be a good indication of the accuracy of the information you have to hand.

Management expectation is important. Around 4 years ago I was asked to price up a large programme of work. I came up with a toppy estimate around 2 years to get the work completed and they thought they could get it done in a year. I was laughed off the programme and replaced. The person that took over was replaced around 2 years ago. They are still going strong hoping to deliver early next year...

Re: Estimate the length of time to complete a project

Posted: July 17th, 2017, 4:47 pm
by snufkin
Management expectation is important. Around 4 years ago I was asked to price up a large programme of work. I came up with a toppy estimate around 2 years to get the work completed and they thought they could get it done in a year. I was laughed off the programme and replaced. The person that took over was replaced around 2 years ago. They are still going strong hoping to deliver early next year...
Back when I was in the software outsourcing business, that was exactly our favourite type of clients: "We want to build X — Okay, that's 1 year and so much — But there's this company, they do it cheaper in half the time — Oh, really? Good luck then — (a year later) You know, we're still struggling to deliver, how much will it be to finish this project?"