TheLadders.com Developer Blog

I've used similar practices for quite a while with great success. Alternatives like critical path dependency tracking just don't enlighten the delivery date. Like eXtreme Programming, Joel took the instinctive solutions that practical developers use and dialed them up to 10:

• Avoid MS Project -- "Use Microsoft Excel": As most software developers know, it's a great tool to organize just about anything, and now I know why (read Joel's article for the answer)!
• List tasks -- "Pick very fine grained tasks"
• Estimate each task -- "Only the programmer can estimate how long each one will take". And don't "let managers tell programmers to reduce an estimate".
• Estimates can change -- This is managed practically by tracking the "Original estimate" and "Current estimate" and updating "the elapsed [time] column every day".
• Account for all the time that will be consumed during the course of the project --> track everything: Vacations, Holidays, Debugging Time, Integration Time, some extra buffer time, and development time.

Commentary

Here's my commentary. You should read Joel's article first. Otherwise, it will be like hearing half a cell phone conversation.

4) Only the programmer who is going to write the code can schedule it.

This is ideal. Although developers initial estimates tend to be fairly inaccurate, they do get better with time. Especially if there's historical feedback about how long a task actually took to compare to. I'm doing this more and more.

I do see a limitation, though. The development group is often called upon to estimate some work effort for planning purposes. The estimate is then used for budgets, hiring plans and scoping decisions. At that early stage, we have two problems:

1. The requirements are to vague to mean much to a developer In this case, I like to get a tech lead to do the estimate. Since we don't have a great deal of insight into what we're building, we supply a Level 1 estimate (E0). The idea here is that it is an early estimate, with a very low level of confidence (see below for how I apply the confidence level for planning purposes). As we get more details on the spec, we can move to an L1, L2, etc. Each one with a successively higher confidence level.

   And, even when we get a better definition of what it is we need to build, we can run into this problem...

2. We don't know when we're going to start the project or what developers will be available when we do start or even how many developers we'll be putting on the project.

   Not much you can do about this. Take your best guess. Maybe have a senior developer who is likely to be a lead for the project do most of the estimating. Make sure that they know that it may be a more junior developer who is doing the actual coding. Your only protection here is a lower confidence rating (or more buffer time).
   

As you get closer to the target date, have some specs to work with and know the developers involved, you can provide a more accurate Level 2 or Level 3 estimate (E2 or E3).

8) Put in line items for Vacations, Holidays, etc.

9) Put debugging time into the schedule!

11) Put buffer into the schedule.

It's terribly important to make your schedules realistic by accounting for real developer time that will be lost to a number of activities.

I start by taking out time lost to being out of the office. Vacation, Personal days, holidays, sick days. At TheLadders.Com this comes out to about 11% (10 holidays + 10 vacation days + 5 personal days + 5 sick days on average / (52 * 5))

I then estimate what portion of time is lost to non-project activities like team meetings, TPS reports and so on. This comes out to around 23%. At TheLadders.Com this includes things like:

• Training (including conferences and lectures)
• Non-project-related meetings
• Time sheets
• Social Committees
• Interviewing new hires (few things are more important than filling that next open req for a Software Engineer)
• Mentoring new hires
• Performance Reviews, grades, goals
• Work on internal presentations

These activities are important for a well run company. Just remember that they do take up time. Even a half hour here and there adds up. Not to mention the added burden of the frequent interruptions.

Unless this is a new development shop, a good portion of time will be spent on maintaining code that is already in production. The time spent on this will vary greatly depending on your situation. How many applications do you have in production? How often do you do releases? Are the same developers that work on new projects, also working on defects?

You have some leeway here to set this number, but if you go too low, you will have a rapidly increasing issue queue and you'll have to manage the debt on that. At TheLadders.Com, we're targeting a fairly trim 20%.

Finally, include some time for post-launch support. No project is perfect, so you can count on having to put out a few fires afterward.

12) Never, ever let managers tell programmers to reduce an estimate.

As developers, we're frequently asked "can't you make that estimate smaller?" Of course we can, but then it would be less accurate than our best guess.

However, it might be helpful for a technical manager (or senior developer) to brainstorm about "cheaper" ways to do it. Ask "What solution did you have in mind when you estimated this?" And "How else can it be done?"

And work with the business owners or product people... they probably don't realize that the lightning bug that flies around under the user's cursor is going to double the cost of the project. Let them know if a particular feature is going to be unduly expensive to build. Maybe the triple validation on the birthday field isn't really that important.

These ARE acceptable ways to reduce an estimate.

Conclusion

This method has in its favor simplicity, adaptability, comprehensibility and, in the end, it sets much better expectations. The point to remember is to make the system, your system. Modify the techniques as much as you need to fit your needs. Every development group and every company is different.