Your clients say they need your project "yesterday." Yep, rapid application development still has its place. Question is, when and where?
Cost, speed, quality: choose two.
- By Mike Gunderloy
- May 01, 2002
— Development trade-off reportedly first enunciated by the project
manager for the Great Pyramid of Cheops
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
- 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
- Technology: Here's where the latest whiz-bang tools fit into
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
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
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@example.com.
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.