Fog Creek Software
Discussion Board

Estimating Development Time...

I am wondering what stratagies you all use to determine a project's timeline.  I'm not talking about large ERP like projects, nor am I talking about small queries or reports.  The projects I am having problems estimating are in the middle.  Something like a new document management section for the company intranet, or a searchable contact management web interface.

While I have improved, I'm still usually 2-3 times off the actual lenght of time it takes.  My current system follows a few simple rules...

#1 - Don't give the boss an estimate before you have gathered all the requirements.

#2 - Don't give the estimate before you have spent a decent amount of time on research and architecture.

The problem I most recently ran into involved #2.  I came across an interface between an object and codebehind ( that I completely missed while designing.  I'm currently scrambling to find the best way to implement it.

I guess I have started to answer my question.  I need a better research and architecture/design phase.  However, I would still like other's input.

Does anyone out there use UML on the medium sized projects mentioned above?  I think something like UML would be beneficial, and I have recently purchased several books on the subject.

I will probably be increasing the architecture/design time component of my projects as a result of this most recent event.

Thursday, July 22, 2004

If you missed an interface then I'd say that what you had was not a detailed design.

I like to give time estimates as follows:

* Research phase: "... depends ..."

* High-level design phase: "... not too long ..."

* Detailed design phase: "... estimate for this phase depends on guess as to size of the project (but having finished the high-level design, at least by this stage I know the scope of the project) ..."

* Coding/implementation phase: "... estimate for this phase isn't available until after the detailed design is complete ..."

The last time I tried this (because my manager required an accurate estimate) I spent as much time on the detailed design as I did on the subsequent coding of it.

Christopher Wells
Thursday, July 22, 2004

Christopher Wells  - What phases, prior to coding, do you break down to?

Thursday, July 22, 2004

It depends on who I'm working for: the manager might have their own Process for me to follow. In the instance I mentioned, it was:

Phase 1

- Get hired (sign HR papers, get a computer, read company documents re coding policy, inspect some of their source, meet coworkers, etc)

Phase 2

- Define requirements (specify which components I will be writing the glue for to interconnect, and specify what functionality will be provided by the new external-components-plus-my-glue system)

Phase 3

- High-level design (high-level architecture for my glue), to be approved by the company's chieft technologist/architect
- Write a whitepaper (a marketing-level document describing the product, for QA, managers, and potential customers)
- Initial project schedule (in this case my estimate was that there was too much work for me to complete it before the marking deadline, so I used the estimate to justify being assigned one or two junior programmers in Phase 5)

Phase 4

- Detailed design: name all my classes, describe the interfaces between my classes (the interfaces between my classes and external components was already specified, in Phase 3) which includes defining any network protocol between classes, describe the threading used, describe state transitions
- Write test cases: needed by QA

Phase 5

Coding and unit testing.

Phase 6

Hand-over to QA.

Add to the above: getting test equipment; coordinating with other developers (e.g. code-reviewing new interfaces they developed); revising the schedule; coordinating with managers (e.g. sales and QA, for tests and demos).

It was fairly waterfall.

Presently I avoid the issue by having a manager who trusts me and who knows we're in a long-term development project: so instead of estimating what I'll do during the next 4 months, I just say what I'm going to do in the next day or week or two, and do that (and then repeat).

Christopher Wells
Thursday, July 22, 2004

1.  Typically, you have to estimate a project long before detailed design.  If you are IN detailed design, then the project must have been approved (from your estimates) some time much earlier.

2.  I usually create a 'strawman' high-level design (created from using the SOW (Statement Of Work) or initial requirements.  I do this mostly so I can focus myself on what pieces need to exist, and to get a rough idea of where they could fit.  This could be tossed later, but I do like to have a high-level approach that my boss approves of that I can estimate with.  Note it takes a day or two, at the most, to read the SOW and draw the straw-man.

This includes identifying 'interfaces' (who needs to know what, and when do they need to know it?  What info is available from users?  Who are the users?)

3.  Having done #2, I now assign approximate 'sizes' to the pieces I've identified.  This database interface piece is simple, so it has around 1500 lines of code or less, and can be done in 160 hours or so.  This business logic piece is large, so it has around 20,000 lines of code or more, and will probably take around 3 months.

4.  Having my sizes of pieces, I now add time for requirements clarification, high level design, low level design, proof-of-concept, coding, and low-level testing (aka unit testing) of each piece.

5.  Now I add elements ( and time ) for integration of pieces, system level testing, one or two cycles of feature addition (when the user wants stuff added/fixed/moved around), creation of documents (Requirements, Design, User Guide, Maintenance Guide).

6.  Now I try to add some 'uncertainty factors' to the design, to try to cope with places my estimates for number of pieces and complexity turn out to be wildly out of reality.

I prefer using Data Flow Diagrams (DFD) for the system level view.  I use UML for software if using C++ or Java (or Ada or VB, for that matter).  (UMLStudio from PragSoft is VERY nice, flexible, and not too expensive.  Rational Rose works OK.  Visual Modeler from Visual Studio Enterprise works OK, also).

Note the UML I find most useful tends to be the Sequence Diagram (shows object communication), tied to the Class Diagram (shows object methods and data).

Thursday, July 22, 2004

Yes, estimation is a tricky process so I searched this forum and found another good link:

Basically, my feeling is that irrespective of how much time you put into the estimation process you'll generally fall wide of the mark because of nasty "gotchas" which were never forseen.

I like the idea that when you arrive at the final figure, you should double it then add another 10% to the timeframe.

YMMV of course.

Thursday, July 22, 2004

I should add - never, never, never give a time estimate to a project manager if he asks for one of the spot. It's more than likely it'll come back to bite you on the ass.

Thursday, July 22, 2004

Check out McConnel's Rapid Development.  He covers this sort of thing in dept.

THe best thing that I've found is using converging estimates.  For your first estimate, come up with a high and a low for a reasonable range.  Then, as the system is being developed and implemented, revise the estimate on a regular basis to narrow down the range.

I've used it with pretty good success so far.

Thursday, July 22, 2004

Agree with KC.  Never give a date, always give a range.  50% margin of error is probably realistic for me, whether or not it's acceptable.

In an interview a few months ago they described what they wanted done for about 45 minutes, then asked me how long it would take, and how large a team we'd need.  This was for a perm job; I've never had such a question during an interview.  Was it a trick question?  Cause only a dufus would make such a wild-ass speculation, right?  I think I said "3 to 9 months" with the straightest face I could muster.  Turns out the "right" answer was 3 months, because that was their schedule.  Heh, I didn't get the job anyway.

Thursday, July 22, 2004

Learning to give a good estimate takes time and experience.  If you're being asked to estimate something that you've never done before - look out!  You'll at least need to take the counsel of someone who has.

It's pretty scary.  It took me about 6 years to learn to produce an accurate estimate.  There is definitely an art to it.
Thursday, July 22, 2004

P.S.  I hate to do this, but I recently wrote an article on what to NOT do when creating an estimate.  Apologies to Joel for spammage, but it's relevant to the discussion:
Thursday, July 22, 2004

Take your best estimate and multiply it by pi.

Also works for budgets.

Friday, July 23, 2004

To take a quote from's article (see post above)...

"That is the secret weapon of estimating - the more small chunks you can reduce the requirements to, the more accurate your resulting estimate will be. But most people are lazy. Analyzing requirements is almost as difficult as gathering them, and again - very few people want to do it. Those that do will consistently deliver more successful projects than those who do not."

I think this distills the problem I originally posted.  On medium sized projects I'm always eager to get moving thinking, "Well this isn't a big project, I can probably wing some of this...".  I definately need to take the time to fully analyze the requirements on ALL projects.  I guess this is the "green" in me showing.  I've only been at this (professionally) for about 3 years.

Thanks for all of your posts!

Friday, July 23, 2004

>Does anyone out there use UML on the medium sized projects mentioned above?  I think something like UML would be beneficial, and I have recently purchased several books on the subject.

>I will probably be increasing the architecture/design time component of my projects as a result of this most recent event.

At the risk of sounding like a broken record (I mention this every few weeks in this forum :-) check out the soon-to-be-released book on the Crystal Clear methodology, especially the section on "What about UML and architecture?".  It breaks down various things -- "thinking time", how long to spend "thinking" before cutting code, UML, drawing tools etc -- which often get lumped together under the "UML" umbrella.  If you split them up, you can re-combine them in more useful and flexible combinations.  See for links re Crystal Clear.

John Rusk
Friday, July 23, 2004

*  Recent Topics

*  Fog Creek Home