Contents
1.1 What Is Rapid Development?
1.2 Attaining Rapid Development
Related Topics
Who should read this book: Preface
Benefits of reading this book: Preface
Why this book was written: Preface
Rapid-development strategy: Chapter 2
Core issues in rapid development: Chapter 6
THE PRODUCT MANAGER TOLD ME he wanted to build a product right for a change. He wanted to pay attention to quality, prevent feature creep, control the schedule, and have a predictable ship date.
When the time came to actually do the project, it became clear that getting the product to market quickly was the only real priority. Usability? We don't have time. Performance? It can wait. Maintainability? Next project. Testing? Our users want the product now. Just get it out the door.
This particular product manager wasn't the manager on just one product. He could have been almost any product manager I've worked for. This pattern is repeated day after day, state by state, all across the country. Development time has become such an important priority that it has blinded people to other important considerations, even to considerations that ultimately affect development time.
To some people, rapid development consists of the application of a single pet tool or method. To the hacker, rapid development is coding for 36 hours at a stretch. To the information engineer, it's RAD—a combination of CASE tools, intensive user involvement, and tight timeboxes. To the vertical-market programmer, it's rapid prototyping using the latest version of Microsoft Visual Basic or Delphi. To the manager desperate to shorten a schedule, it's whatever practice was highlighted in the most recent issue of Business Week.
Each one of these tools and methods is fine as far as it goes, and each can contribute to increased development speed. But to provide full benefit, each must be orchestrated as part of a full-fledged strategy. No one of them applies to all cases. And no one of them can measure up to certain other practices that are not commonly thought of as rapid-development practices but that nonetheless have profound development-speed implications.
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.
A "rapid-development project," then, is any project that needs to emphasize development speed. In today's climate, that description fits a lot of projects.