I gave up on Joel on Software after I got tired with the less-than-interesting articles and a slight holier-than-thou attitude. Let’s just say it no longer was the blog that hooked me. Nonetheless, I have the RSS feed in my Google list and today an interesting topic finally came about, Evidence Based Scheduling. Or in short, estimating using the past as reference.

Funny enough, estimation is always based on history, is it not?

But being programmers and computer people, you have to have hard data before you can make any sort of estimation. I tend to agree, but the detail of data needed to make a good estimate can sometimes be overkill. Of course, I’m now a veteran one-man developer so how I estimate and how I need to estimate vary differently than that of a “real” development team.

Joel’s article discusses the individual tasks involved with any given project. And in turn then breaking that down into time, and so on to collect a full table of data. Naturally, that data is turned into a chart that is supposed to tell you something. In my world, however, individual tasks between A and Z really don’t matter. The only thing that matter’s is that Z happens on or before it’s due. People other than myself don’t really care which path I take so long as the path can be taken economically and on time.

Given that, in order to make a estimate for The Powers I really only need to know one thing: who do I have to rely on?

The largest factor in determining how long a project will take are the people that stand between me and the finish line. If I’m working by myself and can get all the resources myself, projects tend to move pretty fast. Obviously the time it takes to finish goes up the more people you throw in. So if people are the difference between now and later, it’s important to know how those people effect you.

Inspired by Joel’s article, I worked out a spreadsheet I will (hopefully) use to keep track of projects, big and small. Along with the start and end dates for my actual work, I’ve included yes/no columns for each of the type of people I may have to rely for resources. I also include dates for the first time I was told about the project and the due date. Sometimes this is the most valuable information when it comes to defending yourself. There’s nothing better than proving someone didn’t give you information in time when the project is late or lacking on quality.

As far as charting this information…I haven’t gotten that far yet because I just started collecting data. But ideally, after several projects have been tracked, you can run averages on how long any given project, involving any different combination of people, would take you. So the next time someone asks, “when can you have that done by,” you can ask who will be involved in the project besides yourself. With that knowledge you look on your historical chart to get an average of how long a project that involves the Sales department will take.

Now, despite all this and as good as it sounds in my head, this is probably something I will stick with for a handful of projects and then give up on it because estimation is just not that important to what I do…at least not important for me to communicate. It’s important for me so I can get myself on schedule, but not so I can tell me when it will be done.

And the more I continue to develop the more I enjoy taking team ideas and trying boil them down to solo team use. I actually think the solo team is more common than any sort of “real” development team.

This entry was posted on Monday, October 29th, 2007 at 10:34 pm and is filed under All. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.