Fog Creek Software
Discussion Board




Estimating Softare Development Time

I recently had to sit in a talk of how to estimate the duration of a software development task. They came up with the usual trivial stuff everyone would come up when thinking about it as well as some more complicated even including formulas(!).
But my point is: Only a pure theorist or someone desperately in need of another author credit would come up with these things. I happen to give rather good estimates for my projects, but when I look at how long the single tasks making up the project actually took, I have wild deviations in most cases. I think the problem is that in most cases, things go wrong or give problems no one ever even thought of (can we spell 'bug in compiler', API cannot be used as thought, etc.?). I agree that estimations get better throughout the project (I think estimations after 50% were done get pretty good - but on the other hand, it's not so much time left, so deviations tend to be smaller).
Isn't the main dilemma that we have software-developers on one side who would, in a perfect world and knowing how complex software development is, start developing and when an end is in sight start to even thing about a release date. And we have the businessmen in the companies on the other hand, who want to control _everything_ and have a fixed end-date so they can start using Excel to calculate or their fuzzy numbers.
Any thoughts/opinions?

doesitmatter?
Monday, August 05, 2002

Work it out carefully then multiply by four. Best advice I ever received.

Hugh Wells
Monday, August 05, 2002

whatever you do, make sure everyone understands that it is a guestimate.

Most problems occur where one party believes that they have given a guestimate and the other feels that they have received a firm quote.

tapiwa
Monday, August 05, 2002


Heh.  I'd seriously recommend "The Mythical Man-Month" by Fred Brooks and "Extreme Programming Installed" by Jeffries Et Al.

You should be able to find MMM in your local library, and, if you are lucky, XP Installed in the library as well.

In a nutshell:  You are right.  Executives want to "manage risk", and that really means that they want a sure thing: An absolute promise that you will hit the ball out of the park.   

Of course, we all know that the reality is that we'll hit a .300 if we're lucky.

Still, by getting us to comitt, executives "pass the risk" from themselves to us.  Then, if we are late, they can yell and scream and make us take responsibility for the "issue."

heh. 

Extreme Programming lays out a better way.  We measure the work in units of effort, do the most important things first, and begin passing off business value allmost immediately, instead of forcing the customer to wait until the end of the waterfall.  Or read about it for free at http://www.xprogramming.com/xpmag/whatisxp.htm.

regards,

Matt H.
Monday, August 05, 2002

Je recommend reading Steve McConnell "Rapid Development: Taming Wild Software Schedules" which has 2 excellent chapters about work estimation and scheduling. (And the other chapters are also interesting, so it's worth to buy it IMHO)

Robert Chevallier
Monday, August 05, 2002

I meant "I recommend..." (Quel franglais!)

Robert Chevallier
Monday, August 05, 2002

If you are having trouble estimating a task, your task is not fine grained enough. Break it into subtasks and estimate those.

Adding a spell checker is hard to estimate because it's not fine grained enough. "Moving the selection to indicate the next misspelled word" is easy to estimate because it's so fine grained. Your difficulty in estimation probably comes from having a spec that is not well-specified and you really don't know what you're planning to do.

Even with fine grained tasks, you can expect it to take you 3-6 months of estimating and checking your results before you start to get really good at it. The most important thing to learning is to *check your results* so that you get a feedback loop in place. Thus the "Original Estimate" column in Painless Software Schedules.

Joel Spolsky
Monday, August 05, 2002

Vis-a-vis "commitments", be sure to have a written or email trail on this. Verbal estimates of a small portion of a task can become estimates of the entire task in the damaged memory of desparate managers. I have seen this happen in situations in which there was no email summarizing the discussion, and it has led to death-march projects.

skautsch
Monday, August 05, 2002

One item you should surface when talking about estimates is precision.  Ask your customer/manager how precise they want the estimate to be and let them know that precision and estimatation effort vary together;  more precise estimates (less risk) will take more effort to produce.  If they are willing to let you have the time to do the kind of detailed analysis Joel recommends in his contribution above, then you can deliver the kind of precision that comes of it.  If they aren't willing to pay for that level of precision, then so be it; at least you've put them in a position to make an informed decision.

One thing I find helpful in these kinds of negotiations is to turn the estimation problem back on them with simple questions.  For instance, ask them how long it will take them to drive home this evening.  When they reply "45 minutes," ask them "plus or minus what?"  When they say "give or take 10 minutes," you got 'em :)  If  there's a 20% uncertainty on a task they've done hundreds of time with only a few unknowns, how can you do better on a novel task with possibly hundreds of unknowns?

The main thing is not let anyone force you to overconstrain your solution - you have to absorb risk and uncertainty someplace.  To believe otherwise is foolish and naive.

Former Naive Fool
Monday, August 05, 2002

First of all, calibrate your estimates! You have had deviations in the past, analyze them. You may find that even though you didn't notice, some parts are giving you more trouble than others (GUI? Data structures? Using 3rd party components? Documenting?).

Second, even if you don't do pair design or pair programming, do try pair estimation or at the very least get your estimate reviewed and remarked upon by an independent third party (no, your boss does NOT qualify for that job, and neither do your subordinates or your immediate development partners). It helps if the reviewers is experienced, but anyone with a critical eye and a feel for implementation complexity will give you a lot of insight.

Finally, a very useful advice I got some time ago (Don't remember who to credit for it... sorry) - Estimate effort by number of code lines, and only when you've reached concensus with whoever is involved (your critical reviewer, but more importantly - stakeholders), convert that into time. Code lines are (a) a relatively good (though not objective) measure of complexity, (b) is less randomly distributed than time (even though a 30:1 ratio between well done and badly done code is not unheard of), and (c) brings hidden assumptions to the surface much better than any other process I'm aware of. [ .... "How do you get the foobar widget to do that in 20 lines?" "I use it in combination with the Megasoft Kaboodle!" "But that requires installation of heavensoft Bird, and makes the license more expensive" "I wasn't aware" ....]

Ori Berger
Monday, August 05, 2002

Firstly, consider the quality of your development team. This is the most important thing, the people, often overlooked when writing dumb task lists.

I manage a development team of 18, for a moderately detailed program enhancement, I have one team member who would take 3 days, and another who could do it in a morning. The 'slow' team member is still a valuable contributor in other ways (too long to go into).

Then start assigning tasks and making estimates.

Dont forget the people aspect, thats my point.

Alberto
Monday, August 05, 2002

My view is that both software developers and the suits are right. The key is balance.

Yes - it is incredibly difficult to precisely estimate the effort required to develop a complex software application and;

Yes - if the business does not have a fixed (or estimated) release date, nobody will get paid

I believe that "Work expands to fill the time available for its completion" is true for software development as well (of course, provided that "work" is well defined).

So, if you are a software developer in a software development business (as opposed to free-whatever), recognize that shipping your software and getting paid for it comes with the job.

Many estimates get unduly "padded" to cope with uncertainties in requirements - this, in my view does not help anyone - it is far more productive for both sides (geeks and suits) to communicate more openly and agree to revise schedules and resource needs in a fair manner. My experience has been that getting high-level support is essential to attaining some flexibility.

Ask yourself: Who is your head honcho? Geek or Suit? The approach to this eternal challenge is, IMHO, vastly different based on who calls the shots at your company - Geek or Suit?

Jagdish Bajaj
Tuesday, August 06, 2002

Joel is correct - the *most important* item when estimating schedules is task granularity.  Granularity in terms of days is what you should be using when estimating software (or hardware for that matter) tasks.

--- Like in his spreadsheet:
Feature: Graphics Display
Task: Initialize hardware, read PCI info
Start Date: 08/06/02
Estimated Time (days): 1.0
Elapsed Time (days): 1.0
Current Estimate (days): 1.0

Feature: Graphics Display
Task: Map hardware registers to user space
Start Date: 08/07/02
Estimated Time (days): 1.0
Elapsed Time (days): 0.0
Current Estimate (days): 1.0

With this fine of granularity, you and those who depend on your work will know exactly, day by day, what your status iis (no more status reports).

No more miscommunication, everything everyone needs to know is there (make is shared - we keep ours in version control, update it nightly).

Your PM can read it and update gant charts as necessary.  Come review time, you have a complete log of all your tasks and how well you completed them.

As Ori says, calibrate.  You have a history of estimates and your accuracy.  Adjust accordingly.

As Joel said somewhere else (in the interview section of the archives somewhere), if you don't have enough developers to complete a project on schedule, that's not a developer problem, that's a management problem.  All you have a responsibility to do is make your managers aware of your progress - and of course do your best.

Nat Ersoz
Tuesday, August 06, 2002

[The most important thing to learning is to *check your results* so that you get a feedback loop in place. Thus the "Original Estimate" column in Painless Software Schedules]


One thing this type of feedback can give you is a <a href="http://c2.com/cgi/wiki?LoadFactor">load factor</a>. A load factor relates your time estimate wth the real amount of time it took to complete the task. For example - say you estimate that the task would take 8 hours but it actually took 16 because you had to go to meetings, help a coworker with a bug, take a lunch, and you ran into a problem you didn't anticipate (*gasp*). From that estimate you have a load factor of *2. Continue to estimate tasks and calculate the load factor and this will help you come closer to reality. This also helps seniors develop time estimates for projects. If you know that developer x on my team continually has a load factor of *2 in the past and he estimates that a task will take 8 hours, you can tell your PM it will take 16 hours and it is a reasonable estimate.

Ian Stallings
Tuesday, August 06, 2002

I really gotta stop that.

http://c2.com/cgi/wiki?LoadFactor

Ian Stallings
Tuesday, August 06, 2002

"ask them how long it will take them to drive home this evening. When they reply "45 minutes," ask them "plus or minus what?" When they say "give or take 10 minutes," you got 'em :) If there's a 20% uncertainty on a task they've done hundreds of time with only a few unknowns, how can you do better on a novel task with possibly hundreds of unknowns" -- Former Fool

Ooooh! That's a good one. Can't wait to try it out. I bow at your genius.

Former Fool Fan
Tuesday, August 06, 2002

eeccchhh.  estimates?  keep track of past deviations?  sounds too much like engineering.

please don't step on the creativity
Tuesday, August 06, 2002

Yes, it probably is engineering... assuming that engineering is defined as following some sort of set process.  If the process is not set, then feedback to improve it is pretty wasted.

The time it takes to do something... a task or project is more dependent on the "process" that will be used to accomplish it.  The "approach" for lack of a better word right now.

The theory of becomming process dependent only guarantees conformance to process.  There is no guarantee of the quality of the results, and certainly NOT that it will be the fastest way to accomplish the same task or project.  Process strives for consistency of time expended, not relative speed.  This improves estimates and estimates only.

Joe AA
Tuesday, August 06, 2002

Joe AA makes an excellent point about process.  Another thing to look out for with standardized processes is that the standardization tends to optimize the status quo.  When things change, the process can work against you if you don't stay on your toes.  Tom DeMarco has a pretty good exposition of this kind of stuff in his book "Slack"

http://www.amazon.com/exec/obidos/ASIN/0767907698/

Probably relates to that cargo-cult discussion in another thread too.

Slacker
Tuesday, August 06, 2002

The thing that gives you the big. Why? Because the most often recommended suggestion to estimating is to break things down into small tasks. When you are breaking things into small tasks, what are you doing? Software development. The less time you spend breaking the stuff into small tasks, the less accurate your estimates will be. If you break your stuff into detailed enough tasks to give a 99.99% accurate estimate, you're probably 99.99% of the way there already.

Here's the rule of thumb you can follow by. If you did it before? Your estimate is probably correct. If it's new? Your estimate will be off.

Humbug
Friday, August 09, 2002

Woops....submitted without proofing earlier.

Forget trying to estimate software development time if you've never done it before. Why? Because the most often recommended suggestion to estimating is to break things down into small tasks. When you are breaking things into small tasks, what are you doing? Software development. The less time you spend breaking the stuff into small tasks, the less accurate your estimates will be. If you break your stuff into detailed enough tasks to give a 99.99% accurate estimate, you're probably 99.99% of the way there already.

Here's the rule of thumb you can follow by. If you did it before? Your estimate is probably correct. If it's new? Your estimate will be off.

Humbug
Friday, August 09, 2002

*  Recent Topics

*  Fog Creek Home