SERVING THE QUANTITATIVE FINANCE COMMUNITY

 
User avatar
CommodityQuant
Topic Author
Posts: 207
Joined: July 5th, 2007, 6:16 am

Estimate the length of time to complete a project

April 20th, 2017, 8:41 pm

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
 
User avatar
snufkin
Posts: 40
Joined: January 25th, 2017, 9:05 am
Location: Cambridge

Re: Estimate the length of time to complete a project

April 21st, 2017, 9:56 pm

The ultimate guide to estimates like that is given by Joel Spolsky at https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/; the previous version, though he says it's obsolete, is what you want to see: https://www.joelonsoftware.com/2000/03/29/painless-software-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?
 
User avatar
CommodityQuant
Topic Author
Posts: 207
Joined: July 5th, 2007, 6:16 am

Re: Estimate the length of time to complete a project

April 22nd, 2017, 7:07 am

snufkin, Many thanks for some very useful ideas and reference.

CommodityQuant
 
User avatar
ppauper
Posts: 63962
Joined: November 15th, 2001, 1:29 pm

Re: Estimate the length of time to complete a project

April 22nd, 2017, 7:54 am

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.
 
User avatar
DominicConnor
Posts: 11678
Joined: July 14th, 2002, 3:00 am

Re: Estimate the length of time to complete a project

May 18th, 2017, 3:10 pm

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.
 
User avatar
ISayMoo
Posts: 190
Joined: September 30th, 2015, 8:30 pm

Re: Estimate the length of time to complete a project

May 20th, 2017, 7:56 pm

snufkin wrote:
The ultimate guide to estimates like that is given by Joel Spolsky at https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/; the previous version, though he says it's obsolete, is what you want to see: https://www.joelonsoftware.com/2000/03/29/painless-software-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.
 
User avatar
Cuchulainn
Posts: 52272
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Re: Estimate the length of time to complete a project

June 1st, 2017, 9:03 am

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
http://www.datasimfinancial.com

"Science is what you know, Philosophy is what you don't know" Bertrand Russell.
 
User avatar
Cuchulainn
Posts: 52272
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Re: Estimate the length of time to complete a project

June 1st, 2017, 9:10 am

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".
Last edited by Cuchulainn on June 1st, 2017, 9:35 am
http://www.datasimfinancial.com

"Science is what you know, Philosophy is what you don't know" Bertrand Russell.
 
User avatar
Cuchulainn
Posts: 52272
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Re: Estimate the length of time to complete a project

June 1st, 2017, 9:30 am

snufkin wrote:
The ultimate guide to estimates like that is given by Joel Spolsky at https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/; the previous version, though he says it's obsolete, is what you want to see: https://www.joelonsoftware.com/2000/03/29/painless-software-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.
http://www.datasimfinancial.com

"Science is what you know, Philosophy is what you don't know" Bertrand Russell.
 
User avatar
rmax
Posts: 5831
Joined: December 8th, 2005, 9:31 am

Re: Estimate the length of time to complete a project

July 5th, 2017, 1:31 pm

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...
 
User avatar
snufkin
Posts: 40
Joined: January 25th, 2017, 9:05 am
Location: Cambridge

Re: Estimate the length of time to complete a project

July 17th, 2017, 4:47 pm

rmax wrote:
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?"
ABOUT WILMOTT

PW by JB

Wilmott.com has been "Serving the Quantitative Finance Community" since 2001. Continued...


JOBS BOARD

JOBS BOARD

Looking for a quant job, risk, algo trading,...? Browse jobs here...