|< Day Day Up >|| |
You may be content to just write code until the program is done, whenever that happens. But often there are constraints that prevent such a “we’ll ship it when it’s done” mentality from working. For instance, you might need to get a product on the market so as to be able to sell some copies so that you can afford to buy something other than ramen noodles, rice, and beans for dinner. Or you might want to be first to the market to gain a strong competitive advantage. In such cases, you’re going to want to track the progress of your project.
Scheduling software is a difficult problem. In fact, it’s a very difficult problem. It’s so difficult that almost no one does it well, despite the fact that as an industry we have over 60 years’ experience in trying to predict how long it will take to write applications. Still, if you’re trying to allocate resources and finish a product, you’ve got to come up with a schedule.
Most of what you’ll find written about scheduling software projects is aimed at people building very large applications that involve thousands of requirements and large teams of developers (the classic work here is Fred Brooks’ excellent The Mythical Man-Month, 2nd edition, Addison-Wesley, 1995). That’s not us. If you’re developing software in the small, the place to start thinking about scheduling is with Joel Spolsky’s essay “Painless Software Schedules” (www.joelonsoftware.com/articles/fog0000000245.html). In this essay Joel comes up with a set of rules that I’ll quote here with permission:
Use Microsoft Excel.
Keep it simple.
Each feature should consist of several tasks.
Only the programmer who is going to write the code can schedule it.
Pick very fine-grained tasks.
Keep track of the original and current estimate.
Update the elapsed column every day.
Put in line items for vacations, holidays, etc.
Put debugging time into the schedule.
Put integration time into the schedule.
Build a buffer into the schedule.
Never, ever let managers tell programmers to reduce an estimate.
A schedule is like wood blocks: If you have a bunch of wood blocks, and you can’t fit them into a box, you have two choices: get a bigger box, or remove some blocks.
Some of these rules require a bit more amplification; I urge you to go read Joel’s original essay for the details. But I do want to talk about fine-grained tasks for a moment. There’s an art to picking the right tasks to include on a schedule. Inexperienced developers and managers often try to just schedule the major milestones: “user interface,” “downloading code,” and so on. Experienced developers seem to universally agree that this doesn’t work. No matter how much experience you have, any number that you pull out of thin air for developing the user interface will be wrong. In fact, no matter how hard you try, you won’t allow enough time for such major milestones.
If you’re absolutely forced to estimate a schedule based only on milestones (say, because the customer is sitting across the desk from you and wants a number right away), come up with the absolute best, most realistic numbers you can, and then multiply them by three. You can always deliver early, but you can’t slip the schedule without making someone unhappy. A far better plan is to simply say, “I’ll let you know as soon as I can work up a detailed schedule.”
Instead of milestones, when you’re scheduling a software project you should think in terms of inch-pebbles. What’s an inch-pebble? It’s a teeny-tiny task, a small part of a milestone. Instead of scheduling the entire user interface as a single task, schedule individual dialog boxes and forms. You probably have a much better idea of how long it takes to build an individual dialog box than of how long it takes to build an entire user interface for a vaguely defined product. There’s also a great side effect here: By the time you create a schedule at the inch-pebble level, your product will be much less vaguely defined.
I know of two products that implement the Painless Software Scheduling method. One is Positive-g’s Task Tracker (www.positive-g.com/tasktracker/index.html), a stand-alone application that’s available as shareware with a $25 registration fee. The other is Safari Software’s MasterList-XL, a free Microsoft Excel application (www.safarisoftware.com/intro.htm).
Figure 1.2 shows a first cut at a schedule for the DownloadTracker application.
Figure 1.2: Scheduling a new project using Task Tracker
There’s a second aspect of project tracking that some developers need to worry about: time and billing tracking. If you’re getting paid by the hour by an external customer, they probably want you to provide an accurate accounting of your time, and to generate reasonably professional-looking invoices. While you can use a general-purpose accounting package for this, my recommendation is that you evaluate time and billing software aimed specifically at software developers. Two such packages are AllNetic’s Working Time Tracker (www.allnetic.com/) and Atozed Software’s A to Z Project Billing (www.atozedsoftware.com/project/).
These packages are designed to make it easy for you to allocate billable time to projects by recording the time as you work. Either one lets you easily start a timer when you begin a task, and then assign the time to a particular task when you finish. They can then produce reports showing the total time that was assigned to each task. In addition, the Atozed product includes a complete billing system, with clients, employees, and accounts receivable. Both packages have trial versions that you can download and try. If you’re billing by the hour, either one will definitely beat trying to track hours on a scrap of paper or in a spreadsheet. Figure 1.3 shows just one of the reports that you can get from A to Z Project Billing.
Figure 1.3: Tracking hours with A to Z Project Billing
Some developers don’t want to have anything to do with bookkeeping. Unfortunately, unless you’re big enough to hire someone to do nothing but keep track of billing, you’re going to have to pay some attention to that side of the business. It makes sense to spend a little money on a package to make this as painless as possible.
|< Day Day Up >|| |