Scheduling Deliveries

---

Software projects are never on time. OK, maybe there are exceptions to that rule, but it’s a good starting point for thinking about delivery schedules. Most developers are very aware of the three-cornered trade-off shown in Figure 2.2.

Figure 2.2: Trade-offs in software development

One way or another, this triangle has to stay in balance. If you have to add more features to the product corner, then either the time or cost (or both) have to be increased. If time and cost are fixed, then the amount of product you can deliver is also fixed. (If you have a boss that dictates product functionality, time, and cost, beware; he or she may have an impossible combination in mind.)

The realities of business are such that cost and time are usually pretty well fixed, and your only flexibility is in how much product you can deliver on time and within budget. Given this equation, it’s not smart to plan on an all-or-nothing strategy that leaves you with no software at all if the cost and time factors prove to be wrong. By delivering your software in multiple stages, you can be sure to produce something even if your initial estimate of what you can accomplish is wrong.

RULE

Plan on multiple deliveries of any project of reasonable size.

The Beta Testing Approach

One way to handle this is to deliver your entire application in a very crude form at first, and then to refine it into successively better-working builds. Typically, the builds will have names like this:

• Alpha

• Beta 1

• Beta 2

• Release Candidate

• Release

This is the approach that Microsoft takes with its large applications like Office or Visual Studio. The alpha builds go to a few selected people to look at; the beta builds to a somewhat wider audience; and the release candidate builds are widely distributed to catch obscure problems that affect only a few people.

How does this approach handle the trade-offs? Usually, Microsoft fixes the time and cost points by planning a schedule that runs from alpha to final release. The trade-offs are then within product functionality. It’s not unusual, with this approach, for a feature that’s in an alpha or beta build to mysteriously disappear before the product’s final release. This could be because feedback from testers indicated that the feature was unwanted, or it could simply be that the developers ran out of time and money to implement it.

The XP Approach

Note that the beta testing approach amounts to delivering broken software repeatedly, with the hopes that each build will be less broken than the one before. If you’re sure you have the resources to get to a final release version, that’s fine, but what if you run out of time and money at the Beta 1 stage? Software that’s almost totally broken is worse than no software at all.

This problem has led advocates of Extreme Programming (XP) to a different philosophy about releasing software. They advocate a series of small releases. The idea is to put a simple version of the program in operation as quickly as possible, with a high quality bar. Then you prioritize the requirements, and add them in one at a time on successive releases. Releases are spaced close to one another (perhaps two to three weeks apart), and each represents a minimum increment of functionality above the previous release.

The XP approach handles resource constraints almost the same way as the beta testing approach, by adjusting product functionality. But there’s a difference between the two if the constraints get unexpectedly tight. Suppose your development budget were chopped off half-way through the project. With a beta testing approach, your final release might have implemented 100% of the planned functionality, but with lots of bugs in every function. With the XP approach, your final release might only have implemented 50% of the planned functionality, but that 50% will be close to bug-free.

Choosing a Scheduling Approach

Choosing between a typical beta testing approach and an XP “small releases” approach is usually a matter of understanding your resources and audience. If you’re working in a business setting with uncertain requirements and a potentially shaky contract, I urge you to go for a more XP-like schedule. You can maximize your chance of a happy customer by making sure that they have a working system at all times, even if it doesn’t (yet) do everything that they’re hoping for.

On the other hand, if you’re creating a utility for sale on the Internet, you might find a beta testing approach more to your liking. Even if you’re not facing external constraints on your time, the feedback from beta testers has a value all by itself. By pushing out an early version with a rough cut of your planned functionality, you can get an idea as to whether the market is really interested in this software.

Tip

Before releasing a beta test version, you should think about licensing issues. I’ll talk more about this in Chapter 14, “Protecting Your Intellectual Property.”

Whatever you do, don’t make the mistake of thinking of the Product corner of the triangle (Figure 2.2) as “product quality” instead of “product functionality.” It can be tempting at the end of a long development cycle to shove a product out the door even if you know that it’s full of bugs. Resist the temptation. There’s no better way to lose customers permanently than to sell them software that doesn’t work.

---