Rapid Development

Your clients say they need your project "yesterday." Yep, rapid application development still has its place. Question is, when and where?

• By Mike Gunderloy
• May 01, 2002

With the collapse of the dot-com boom, we don't hear as much about "Internet time" as we used to. But that doesn't mean that the pressures for rapid development are gone; it just means that fewer people believe that a TCP/IP connection will magically make your software get finished sooner. Instead, I'm finding a renewed interest from many developers and their managers in exploring processes and methods to develop software more quickly. In this column, I'll take a look at some resources that can help you move in the direction of more rapid development.

But first, a caution: the classic three-way tradeoff still holds:

• You can develop software less expensively and more quickly if you don't care about quality.
• You can develop high-quality software more quickly if you don't care about cost.
• You can develop high-quality software less expensively if you don't care about speed.

If you refuse to let developers leave their desks to attend committee meetings and force them to make a choice, most managers will reluctantly admit that high quality is a requirement, and face the fact that rapid development practices can require additional budget. (The rest of the managers will just wail plaintively, "But I want all three!") Before you embark on a course of rapid development, you need to make sure that you've got adequate backing from the level in your organization that can make spending decisions. Otherwise, as you explore the many alternatives you'll end up feeling like a kid in a candy shop without even a single penny to spend on a sucker.

What Is Rapid Development, Anyhow?
Steve McConnell wrote an entire book titled Rapid Development (Microsoft Press, 1996). He defines rapid development this way:

Rather than identifying a specific tool or method, for purposes of this book "rapid development" is merely a descriptive phrase that contrasts with "slow and typical development." It isn't Rapid Development™—a magic phrase or buzzword. It isn't a glitzy Blaze-o-Matic® or Gung-HO-OO™ rapid-development methodology. Rapid development is a generic term that means the same thing as "speedy development" or "shorter schedules." It means developing software faster than you do now.

If the words "rapid development" automatically makes you think "RAD Tools", and brings to mind debates over the relative merits of different IDEs and programmers' editors, then you need to go back and read that paragraph again. There are many ways to approach rapid development. McConnell identifies four dimensions of development speed:

• People: Some people and teams work faster than others. You can influence this by staff selection, team organization, and motivation.
• Process: Much as some developers hate to admit it, process issues—from formal planning to quality assurance goals to resource targeting—can have a major impact on development speed.
• Product: Product size and feature set have an obvious influence on development speed. Don't overlook the 80/20 rule for products, for example: if 80 percent of your customers only need 20 percent of the product's functionality, can you identify and ship that 20 percent as version 1?
• Technology: Here's where the latest whiz-bang tools fit into the picture.

Many developers focus almost exclusively on technology and, to a lesser extent, process (that's where the recent rise in Extreme Programming practices fits in, for example) when trying to develop more rapidly, while ignoring the people and product dimensions. That's OK as long as you have a good manager to coordinate these things with the people and product dimensions. If that doesn't make sense to you, you might want to take a look at the Manager FAQ (http://www.plethora.net/~seebs/faqs/manager.html).

Finding Your Happy Place
I could try to exhaustively enumerate useful rapid development practices here—but I have 1,500 words, and it took McConnell more than 200 pages to list 27 best practices for rapid development. So I urge you to buy a copy of his book (the other 400 pages are worthwhile, too). Instead of trying to be exhaustive, I'll just mention a few of the practices that he goes into that you may not be familiar with:

Inspections One of the best way to avoid the "man in a dark room" syndrome, where developers vanish for months at a time and don't get any feedback, is to hold formal code inspections and walkthroughs. As with many other rapid development practices, the paradoxical-seeming effect is that spending time on inspections will save you time in the long run, because you'll find and fix bugs sooner.

Measurement How do you know whether you're improving? Only by measuring things. McConnell has a strong chapter on measurement that discusses what to measure and how to measure it. Like the rest of the book, this chapter is anchored by hard data from a variety of studies.

Miniature milestones A scheduling practice that can help keep a project moving along at a rapid clip.

Signing up Structured thinking about teamwork comes into play here. How do you know that your whole team really wants to ship the product, instead of just coming in for the paychecks?

Timebox development Redefine the project to fit the schedule, instead of the other way around. An absolutely fixed schedule is the best way to avoid the "90-90" problem, where a system is quickly "90 percent complete" and then stays there for 90 percent of the time spent on the project.

I could go on, but instead I'll just say: You should pick up a copy of this excellent book, and read it, if you're at all responsible for actually shipping software.

Report Card Time
But wait! Maybe your team is already doing rapid development. Or at least, you think they're pretty darned good. But how do you know for sure? Well, you could spend a whole lot of time and money learning and applying the Capability Maturity Model for software (http://www.sei.cmu.edu/cmm/). But my guess is that if you're working for an organization that can benefit from that heavy-handed a process, you're already familiar with the CMM. For the rest of us, you can get a pretty darned good idea of where you stack up by taking The Joel Test (http://joel.editthispage.com/articles/fog0000000043.html). The Joel Test is the brainchild of Joel Spolsky, who appears to be building a career as a software manager, author, and pundit simultaneously. The thing is, he's good at all of them (I've read his book and used some of his software, and now I'm pointing you at his punditry), so he must be doing something right.

The Joel Test is a paltry dozen questions that checks up on whether you're following some common best practices, things like source code control, daily builds or bug tracking. You'll probably read his discussion and think of each one of his points as being a "mom and apple pie" ideal that no one can argue with. But if that's true, why are so many organizations far short of a perfect 12 on the Joel Test? I thought about how a couple of my consulting clients from long ago would have fared on this test. The big Fortune 500 corporation came in at a 2. The well-funded government agency managed a 1. Perhaps if they'd scored better they could have actually finished the projects that they were throwing coders at.

Anyhow, if you're developing software, go take the Joel Test. If you score less than 10 or 11, think seriously about whether you'd better get your process fine-tuned before you write any more code. You may discover that you don't need any fancy rapid development techniques if you just get up to a good baseline process.

So, What About Tools?
I've argued in the past that concentrating on tools is too narrow a focus for improving software development. But it's undeniable that good tools can help produce good software faster. And, of course, good tools are fun. That's why I'm going to devote my entire next column to my annual roundup of nifty tools for software developers. If you'd like to help influence the column, drop me a line at [email protected]. I'm especially interested in your answers to two tool-related questions:

• What tools and utilities would you hate to have to do without?
• What tools do you wish you had that you haven't been able to find?

I'll report back next month with some of your suggestions, as well as my own pick of the current pack of tools. Comments may be used in a future issue of "Developer Central" or this column, unless you ask me to keep them confidential.