Fog Creek Software
Discussion Board

Debugging and head-banging in estimates

Recently, I've tried to improve my accuracy in the creation of software schedules. 

For starters, Joel wrote an article on it -

But I've looked into PSP, XtremeProg, Risk-Adjusted Estimates, functional decomposition, guru method, etc.

So I'm writing a schedule for a piece of software ... and I want to nail it this time.

First, I put in how long I think it should take me to do each feature.  Then I sub-total.  Then I add some debugging time (about one-third), then I evaluate the risk and add a mark-up for risk.  (On this project, I added 30% to the sub-total)

Here's the question:  Do you think I have allotted enough time for debugging and head-banging?  Joel suggests that I actually add time for BOTH debugging AND buffer - and submits that debugging can be up 100% or 200% of the original estimate!

My numbers are more like 30% for debug and 30% for head-banging.

Still, I'm relatively confident that I designed the feature well up-front, and I understand what I'm going to do.  (As opposed to having hand-waving functions like "validate data" that I haven't defined.)

Any thoughts?


Tuesday, November 19, 2002

I make pessimistic estimates for every little task. I do not add any time for debugging in general. I have done this for over a year and I've always ended up very close to my initial estimate.

Big B
Tuesday, November 19, 2002

Another nice thing to do w/ the riskier tasks is to do those tasks first, even if it requires the writing of scafolding code to get it working. This way, the tasks for which the estimates are most difficult to estimate get corrected first. Therefore the average certainty steadily increases as the most uncertain tasks are completed.

Tuesday, November 19, 2002

Time estimates are like share prices.
Every share has an intrinsic value, i.e what it's 'truly' worth.
Also, a share is worth what somebody will pay you for it.

Classic "intrinsic value" vs "castle in the air" theory.

Estimates are the same, work out how long you think it will take, i.e its value, and then shoot for how ever long you think they'll give you.

Of course, estimation is a totally different game if your spending somebody elses money and not your own.

Software engineering is about money, just like all other sorts of engineering.

Wednesday, November 20, 2002

My point being, use whatever system is most generous.

Wednesday, November 20, 2002

The hard part of schedule estimates is bounding things that are unbound.  That is, itemize the things that you:
1. Haven't previously done something similar.
2. Relies on 3rd party source code, deliverables, hardware or documentation.

These are the high risk items.  Everything else (am I missing something?) should be within your control and you should be able to estimate accurately based on past results. 

Take the high risk items, once listed, and break them down as far as you can go.  What is the riskiest part of the risk?  What are the blockers? 

What you should have is a schedule which is a list of tasks.  Some tasks have hard estimates which you think you can meet with good certainty, and a highlighted list of tasks which have high uncertainty.  The high risk items will remain high risk until you've coded them and brought them to near functiional level.

That's about as good as you can do.  That and keep the list up to date and transparent.  Don't hide anything and keep your boss informed of your progress.

Nat Ersoz
Wednesday, November 20, 2002

The best way I have found for improving schedule estimates is by keeping old estimates, which have both original estimated time and the time actually taken.

After producing a schedule, find an estimate from one of your old project schedules for some similar piece of work and compare it against the estimates you have for the current schedule. Compare both sets of figures (ie estimate vs actual). You might have a think about what caused the discrepency and make a not on the schedule (obviously not a publically available copy).

I am now much better at schedules than I was even a few years ago.

>Another nice thing to do w/ the riskier tasks is to do those tasks first,
Indeed. The common name for this is “ring-fencing”, whereby items that involve a higher degree of risk do not impact others. This applies equally to schedules and the software itself; particularly the software. You should definitely be doing this.

>These are the high risk items.  Everything else (am I missing something?)
Changes to requirements (perhaps based on the schedule) are not something you have a great deal of control over.

Also, people spending money do not like to see holes in the schedule or items marked as ‘contingency time’. To them it is just expensive programmers sitting about doing nothing. They would rather fill the time with new features or something.

Somebody once told me that a good way to estimate function points (as opposed to making a schedule) is 1 day per function point per table. Eg to write a “user details” screen will take 1 day for Add/Amend/Delete. Obviously this assumes that you are working with a database. My experience indicates that this seems to be the case, although it needs to be tempered with a degree of common sense. It patently will not take a day if your user details consist of 250 fields of differing types, populated mainly with lookup data. It may take a good deal less if you only have a couple of fields and suitably similar code which can be stolen to order.

Where was I? Oh yes, 1 day per function point per table. The main adavantage is that it allows non-technical people to see where all the time goes and allows for an approximation of profit (multiply by you daily rate). This allows you to determine whether its worth undertaking a project for someone.

Use it or don’t; it’s a tool like any other, as long as you know it may not be greatly accurate, that’s OK. “Sloppy”, I believe the proprietor of this establishment would call it.

Sunday, November 24, 2002

Sorry, paragraph 2 should read "make a note on the schedule".

*Yes*, I proof read it, but I'm only human.

Sunday, November 24, 2002

*  Recent Topics

*  Fog Creek Home