Slow development affects everyone involved in the software development process, including clients, developers, end-users and managers. All software development teams want to solve this one major problem—how to increase development speed while having high-pressure development schedules under control. In Rapid Development, written by Steve McConnell, the author emphasises efficient development ideas by examining rapid development strategies and studying classic mistakes within the circumstance of software-development fundamentals and risk management. Breaks down the core issues of rapid development, lifecycle planning, estimation and scheduling.
HOW THIS BOOK HELPED US?
Rapid Development showed us how to increase the speed of software development and described the development speed limits to help us have a firm foundation for distinguishing between realistic improvement programs and wishful-thinking fantasies.
THE BOOK EXPLAINED UNDER 60 SECONDS
The road mapped out in this book is the road less travelled in today’s industry. This book discusses how software development teams can increase the speed of software development, allowing you to deliver software faster. Rapid Development also highlights Practices that make progress visible, allowing you to dispel the appearance of slow development.
TOP THREE QUOTES
“Choose your battles. If rapid development is a top priority, don’t shackle your developers by insisting on too many priorities simultaneously.”
“Even if you do a few things right, such as making high use of modern programming practices, you might still make a mistake that nullifies your productivity gains.”
“Study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor.”
BOOK SUMMARIES AND HIGHLIGHTS
PART I: EFFICIENT DEVELOPMENT
Chapter one: Welcome to Rapid Development
What Is Rapid Development
To some, rapid development involves applying a sole pet tool or method. Hackers refer to this as writing code for 36 hours straight. To an information engineer, RAD combines thorough user involvement, CASE tools and tight timeboxes. All these methods and tools are ideal and can fully contribute to increased development speed. According to the book, Rapid development is a descriptive phrase that means developing software faster than the usual approaches. A rapid development project is any project that needs to put its emphasis on development speed. In the present day, many projects fall under that description.
Attaining Rapid Development
To achieve rapid development, you must consider these two aspects: selecting effective practices over ineffective practices and selecting objective-oriented techniques. Development speed usually depends on the development practices established. How swiftly you design a specific product is determined by the extent to which you select effective and schedule-oriented techniques. There are three schedule-oriented practices: Speed-Oriented Practices, Schedule-Risk-Oriented Practices and Visibility-Oriented Practices. Your agitating concerns about development speed determine the sort of schedule-oriented practices you choose. If you think you must increase your development speed, then focus on speed-oriented practices. If you anticipate that your speed is ok, but your customer’s perception of your rate is the problem, then align your attention toward visibility-oriented practices.
Chapter two: Rapid Development Strategy
General Strategy for Rapid Development
Rapid development can be achieved by following a four-part strategy. The four parts include; Avoiding classic mistakes, implementing development fundamentals, managing risks to avoid catastrophic setbacks and implementing schedule-oriented practices. Have all pillars in place and make them as strong as possible. The first three pillars greatly determine your potential to attain the best schedule. The first three pillars provide the support needed for the best possible schedule. Not ideal support, perhaps, but most of what’s required. You might be able to achieve an optimal schedule without schedule-oriented practices.
Four Dimensions of Development Speed
Whether you’re operating slowly to avoid mistakes or moving at high speed with the best schedule-oriented practices. Your software project operates with the help of four essential dimensions: process, people, product and technology. First, people have the most impact on software development, productivity and quality than any other factor. Clearly, any company that wants to improve productivity must consider peopleware issues first. Second, the process of software development includes both technical and management methodologies. Focusing on processes increases quality assurance, helps in risk management and enables you to avoid reworking. Product: this is the most tangible dimension. Focusing on product size and characteristics presents enormous schedule reduction opportunities. If you can reduce a product’s feature set, you can reduce the product’s schedule. Lastly, technology: when you switch your tech tools, chances are that you will improve your development speed. You can change from less effective means to more productive tools.
Chapter three: Which Dimension Matters the Most?
Analyse your project to determine which of the four dimensions are limited and which you can leverage to maximum advantage. Then stretch each to the utmost. That, in a nutshell, is the key to successful rapid development.
Favourite quote of the part: “The first conclusion is that we now know with certainty that peopleware issues have more impact on software productivity and quality than any other factor.”
PART II: RAPID DEVELOPMENT
Chapter one: Does One Size Fit All
Different projects have different rapid-development requirements, even when they all need to be developed “as fast as possible.” Generally, products that are extensively distributed must be designed more carefully than products that are narrowly distributed. Products with critical reliability must be developed more carefully than products whose reliability is secondary. This implies that you must customise a solution that fits your situation.
What kind of Rapid Development Do You Need?
Rapid development’s gist rotates around determining what kind of rapid development approach you desire. Is it a slight speed edge, better progress visibility, lower cost or more predictability? Many people think they need rapid development, but in reality, they need lower prices and more predictability or an approach to avoid a tragic failure. To determine what kind of rapid development you need, ask yourself these questions;
- How strong is the product’s schedule constraint?
- Does the project’s emphasis on schedule arise because it’s a common rapid development look-alike?
- Is the project restricted by any weaknesses that prevent a rapid-development success?
Products that have to focus on development speed rather than cost or predictability have a different time value compared to typical products. As time goes by, the value of specific products usually reduces gradually. But for products with solid schedule constraints, there is a point where they decline precipitously.
Before you align your project toward the shortest schedule rather than the least cost, minimal risk, or best performance, discover what is needed. Rapid-development look-alikes call for all-out development speed but call for something else.
Chapter two: Lifecycle Planning
A lifecycle model is a prescriptive model of what happens between the first glimmer and the last breath. Every software development effort goes through a lifecycle comprising all activities between the beginning and the end. The most familiar lifecycle model is the well-known waterfall lifecycle model, which has some
equally notable weaknesses. Other lifecycle models are available, and in many cases, they are better choices for rapid development than the waterfall model.
Pure Waterfall
The waterfall model is the basis for other effective lifecycle models, as it’s associated with many problems. In the waterfall model, a project advances in an orderly course of steps from the initial software concept through system testing. At the end of each phase, the project is reviewed to determine whether it’s in a position to advance to the next step—from requirements analysis to architectural design. If the review outlines that the project isn’t set to move to the next phase, it remains in the current step until it is ready.
Code-and-Fix
The code-and-fix model is standard but could be more helpful. If you haven’t selected another lifecycle model, you must use code-and-fix by default. Using the code-and-fix model means starting with a general idea of what you want to create. You might have a formal specification or not. Then utilise any combination of informal design, code, debug, and test methodologies at your convenience until you have a product ready to release. This model has no overhead, meaning you don’t spend time on planning, quality assurance or documentation other than coding. It also calls for little expertise. Anyone familiar with computer programs can use the code-and-fix model.
Spiral
This model breaks down a software project into mini-projects and is highly risk-oriented. Every mini-project addresses significant risks until there aren’t any risks to manage. Risk in this context refers to incompetent requirements, performance problems, poorly understood architecture and many more. As soon as the stakes have been handled, the spiral model terminates like the waterfall model. In the spiral model, you begin on a small scale in the centre of the spine, identify and inspect all the risks, formulate a plan to control the risks and finally commit to an approach for the next iteration. The spiral model provides at least as much management control as the traditional waterfall model. You have the checkpoints at the end of each iteration. Because the model is risk-oriented, it provides early indications of any insurmountable risks.
Chapter three: Estimation
Software estimation is quite complex. Upper and lower management, customers, and some developers don’t understand why estimation is so hard. The basic software estimation story is that software development is a process of gradual refinement. You begin with a fuzzy picture of what you want to build and then spend the rest of the project trying to clarify that picture. Because the image of the software you’re trying to develop is fuzzy, the estimate of the time and effort needed to build it is unclear, too. The forecast can come into focus only along with the software itself, which means that software project estimation is also a process of gradual refinement.
Chapter four: Scheduling
Overly Optimistic Scheduling
Overly optimistic software schedules are a faded tradition in software development. All essential programming issues are emergencies, and many software projects need more calendar time. Excessive schedule pressure is the most destructive influence in software. Most projects set their schedules before requirements are fixed and don’t set them without time to spare. The causes of overly optimistic schedules are profound and include; Managers or customers refusing to accept a range of estimates and making
plans based on a single-point “best case” estimate. Managers and developers deliberately underestimate the project because they want a challenge or like working under pressure. The project is deliberately underestimated by management or sales to submit a winning bid.
Beating Schedule Pressure
Schedule pressure is endemic to software development and has generated negative short-term thinking. One, it has encouraged shortcut-taking on particular projects, resulting in poor delivery. Two, it has prompted a fire-fighting mentality about schedule pressure itself. We can’t solve the problem of rapid development until we solve the problem of schedule pressure.
Favourite quote of the chapter: “Every software-development effort goes through a “lifecycle,” which consists of all the activities between the time that version 1.0 of a system begins life as a gleam in someone’s eye and the time that version 6.74b finally takes its last breath on the last customer’s machine.”
PART THREE: BEST PRACTICES
Chapter one: Change Board
This approach controls changes made to a software project. A changing board integrates representatives from development, user documentation, QA, customer support, management and marketing, giving them paramount authority to accept and reject suggested changes. This approach contributes to rapid development by minimising the number of uncontrolled changes to the product and raising the visibility of feature creep. Change boards can be brought into play in any kind of environment.
Chapter two: Daily Build and Smoke Test
Through the Daily Build and Smoke Test process, a software product is built every day and tested several times to verify its primary operations. This process can be instituted while the project has already commenced. This process minimises overdue risks, poor progress visibility and unsuccessful integration. The process provides critical control for projects in recovery mode. Its success depends on developers taking the approach seriously and on well-designed smoke tests. The Daily Build and Smoke Test can be used effectively on projects of virtually any size and complexity. The idea behind the daily build-and-smoke-test process is simple: build the product and test it daily.
Chapter three: Designing for Change
Designing for Change is a comprehensive implementation that encloses many change-oriented design practices. For these practices to be effective, they must be implemented during the early stages of the software lifecycle. The success of this approach depends on identifying suitable changes, developing a change plan and hiding design decisions so changes do not ripple through a program. Some of the change-oriented design practices are more complex than people anticipate. When implemented correctly, these practices lay the groundwork for long-lived programs and flexibility that minimises late-breaking change requests’ schedule effects. Designing for change” does not refer to any single design methodology but to a panoply of design practices contributing to flexible software designs.
Chapter four: Evolutionary Delivery
Evolutionary Delivery is a lifecycle model that balances Staged Delivery’s control and Evolutionary Prototyping’s flexibility. It provides its rapid-development benefit by delivering selected portions of the software earlier than possible, but it does not necessarily deliver the final product any faster. It gives some ability to change product direction mid-course in response to customer requests. Evolutionary Delivery has been used successfully on in-house business software and shrink-wrap software. Used thoughtfully, it can lead to improved product quality, reduced code size, and a more even distribution of development and testing resources. As with other lifecycle models, Evolutionary Delivery is a whole-project practice: if you want to use it, you must start planning to use it early in the project.
Favourite quote of the chapter: “Too much overtime and schedule pressure can damage a development
schedule, but a little overtime can increase the amount of work accomplished each week and improve motivation.”
HOW THIS BOOK CAN HELP SOFTWARE DEVELOPERS
“Rapid Development” by Steve McConnell is a comprehensive guidebook for software developers that provides practical advice and techniques to increase the speed and efficiency of the software development process. The book covers various topics such as project planning, requirements gathering, design, coding, testing, and project management. The book also discusses best practices and strategies for managing risk, reducing errors, improving communication, and enhancing the overall quality of software development projects. McConnell draws on his extensive experience in the field and provides numerous real-world examples to illustrate his points. Overall, “Rapid Development” is a valuable resource for developers who want to improve their productivity and the quality of their work. The book offers practical, actionable advice to help developers of all levels become more effective and efficient.
