Whether you're bogged down trying to avoid mistakes or cruising at top speed with highly effective schedule-oriented practices, your software project operates along four important dimensions: people, process, product, and technology. People perform quickly, or they perform slowly. The process leverages people's time, or it throws up one stumbling block after another. The product is defined in such a way that it almost builds itself, or it is defined in a way that stymies the best efforts of the people who are building it. Technology assists the development effort, or it thwarts developers' best attempts.
You can leverage each of these four dimensions for maximum development speed. Figure 2-3 illustrates the point.
Figure 2-3. The four dimensions of development speed—shown here in two dimensions. You can focus on all four dimensions at the same time.
In response to this diagram, I can almost hear some engineers saying, "Hey! That's not four dimensions. It's four directions. You can't even draw in four dimensions!" Well, you're right. I can't draw in four dimensions, which is why I've shown this illustration in two dimensions. But the concept I want to get across is very much one of dimension rather than direction.
Software development books tend to emphasize one dimension and down-play the others, but there isn't necessarily a trade-off between emphases on people, process, product, and technology. If these were directions, a focus on people would detract from a focus on technology. A focus on product would detract from a focus on process. But because they're dimensions, you can focus on people, process, product, and technology all at the same time.
Software organizations tend to view the dimensions they don't focus on as fixed, and I think that's one reason that project planning can be so frustrating, especially schedule planning. When you focus on a single dimension, it can be nearly impossible to satisfy everyone's objectives. Truly rapid development requires you to incorporate a variety of kinds of practices (Boehm et al. 1984, Jones 1991). The organizations that are the most effective at achieving rapid development optimize all four rapid-development dimensions simultaneously.
Once you realize that each of the four dimensions can potentially provide tremendous leverage over a software schedule, your planning can become fuller, more creative, more effective, and better able to satisfy you and the other concerned parties.
The following subsections introduce the four dimensions and discuss the synergy among them.
Results of individual experiments on peopleware issues are well known. You might be familiar with the claim that there is at least a 10-to-1 difference in productivity among different developers. Or you might be familiar with the positive contribution that an explicit motivational improvement program can have.
What is less familiar to most developers, indeed to most people in the industry, is that the research on peopleware issues has been steadily accumulating over the past 15 to 20 years. It is now possible to step beyond the many individual-study conclusions and synthesize some general conclusions from trends in the research.
The first conclusion is that we now know with certainty that peopleware issues have more impact on software productivity and software quality than any other factor. Since the late 1960s, study after study has found that the productivity of individual programmers with similar levels of experience does indeed vary by a factor of at least 10 to 1 (Sackman, Erikson, and Grant 1968, Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Valett and McGarry 1989).
Studies have also found variations in the performance of entire teams on the order of 3, 4, or 5 to 1 (Weinberg and Schulman 1974; Boehm 1981; Mills 1983; Boehm, Gray, and Seewaldt 1984). After 20 years of experimentation on live projects, researchers at NASA's Software Engineering Laboratory have concluded that technology is not the answer; the most effective practices are those that leverage the human potential of their developers (Basili et al. 1995).
Because it is so clear that peopleware issues strongly influence productivity, it is also now crystal clear that any organization that's serious about improving productivity should look first to the peopleware issues of motivation, teamwork, staff selection, and training. There are other ways to improve productivity, but peopleware offers the greatest potential benefit. If you are serious about rapid development, you have to be serious about peopleware issues. Taken collectively, peopleware issues matter more than process, product, or technology. You have to address them if you want to succeed.
This conclusion is a strong one, but it should not be taken as support for any peopleware initiative whatsoever. The research results simply say that the effects of individual ability, individual motivation, team ability, and team motivation dwarf other productivity factors. They do not say specifically that team T-shirts, free soda pop, windowed offices, productivity bonuses, or Friday afternoon beer busts improve motivation, but the implication is clear: any organization that wants to improve its productivity should be actively trying all these things.
This book deals with several ways that you can maximize human potential to reduce software schedules.
CROSS-REFERENCE
For more on job matching and career progression, see Work Itself in Using the Top Five Motivation Factors. For more on team balance and problem personnel, see Chapter 12, Chapter 12, and Chapter 13, Chapter 13.
Staff selection for team projects. In his landmark book, Software Engineering Economics, Barry Boehm presents five principles of software staffing (Boehm 1981):
Top talent—Use better and fewer people.
Job matching—Fit the tasks to the skills and motivation of the people available.
Career progression—Help people to self-actualize rather than forcing them to work where they have the most experience or where they are most needed.
Team balance—Select people who will complement and harmonize with each other.
Misfit elimination—Eliminate and replace problem team members as quickly as possible.
Other factors that can make a difference include people's design ability, programming ability, programming-language experience, machine and environment experience, and applications-area experience.
Team organization. The way that people are organized has a great effect on how efficiently they can work. Software shops can benefit from tailoring their teams to match project size, product attributes, and schedule goals. A specific software project can also benefit from appropriate specialization.
Motivation. A person who lacks motivation is unlikely to work hard and is more likely to coast. No factor other than motivation will cause a person to forsake evenings and weekends without being asked to do so. Few other factors can be applied to so many people on so many teams in so many organizations. Motivation is potentially the strongest ally you have on a rapid-development project.
Process, as it applies to software development, includes both management and technical methodologies. The effect that process has on a development schedule is easier to assess than the effect that people have, and a great deal of work is being done by the Software Engineering Institute and other organizations to document and publicize effective software processes.
Process represents an area of high leverage in improving your development speed—almost as much as people. Ten years ago it might have been reasonable to debate the value of a focus on process, but, as with peopleware, today the pile of evidence in favor of paying attention to process has become overwhelming. Organizations such as Hughes Aircraft, Lockheed, Motorola, NASA, Raytheon, and Xerox that have explicitly focused on improving their development processes have, over several years, cut their times-to-market by about one-half and have reduced cost and defects by factors of 3 to 10 (Pietrasanta 1991a, Myers 1992, Putnam and Myers 1992, Gibbs 1994, Putnam 1994, Basili et al. 1995, Raytheon 1995, Saiedian and Hamilton 1995).
Some people think that attention to process is stifling, and there's no doubt that some processes are overly rigid or overly bureaucratic. A few people have created process standards primarily to make themselves feel powerful. But that's an abuse of power—and the fact that a process focus can be abused should not be allowed to detract from the benefits a process focus can offer. The most common form of process abuse is neglect, and the effect of that is that intelligent, conscientious developers find themselves working inefficiently and at cross-purposes when there's no need for them to work that way. A focus on process can help.
Rework avoidance. If requirements change in the late stages of project, you might have to redesign, recode, and retest. If you have design problems that you didn't find until system testing, you might have to throw away detailed design and code and then start over. One of the most straightforward ways to save time on a software project is to orient your process so that you avoid doing things twice.
Raytheon won the IEEE Computer Society's Software Process Achievement Award in 1995 for reducing their rework costs from 41 percent to less than 10 percent and simultaneously tripling their productivity (Raytheon 1995). The relationship between those two feats is no coincidence.
Quality assurance. Quality assurance has two main purposes. The first purpose is to assure that the product you release has an acceptable level of quality. Although that is an important purpose, it is outside the scope of this book. The second function of quality assurance is to detect errors at the stage when they are least time-consuming (and least costly) to correct. This nearly always means catching errors as close as possible to the time that they are introduced. The longer an error remains in the product, the more time-consuming (and more costly) it will be to remove. Quality assurance is thus an indispensable part of any serious rapid-development program.
CROSS-REFERENCE
For more on quality assurance, see Quality-Assurance Fundamentals, Quality-Assurance Fundamentals.
Development fundamentals. Much of the work that has been done in the software-engineering field during the last 20 years has been related to developing software rapidly. A lot of that work has focused on "productivity" rather than on rapid development per se, and, as such, some of it has been oriented toward getting the same work done with fewer people rather than getting a project done faster. You can, however, interpret the underlying principles from a rapid-development viewpoint. The lessons learned from 20 years of hard knocks can help your project to proceed smoothly. Although standard software-engineering practices for analysis, design, construction, integration, and testing won't produce lightning-fast schedules by themselves, they can prevent projects from spinning out of control. Half of the challenge of rapid development is avoiding disaster, and that is an area in which standard software-engineering principles excel.
CROSS-REFERENCE
For more on development fundamentals, see Technical Fundamentals, Technical Fundamentals.
Risk management. One of the specific practices that's focused on avoiding disaster is risk management. Developing rapidly isn't good enough if you get your feet knocked out from under you two weeks before you're scheduled to ship. Managing schedule-related risks is a necessary component of a rapid-development program.
Resource targeting.Resources can be focused effectively and contribute to overall productivity, or they can be misdirected and used ineffectively. On a rapid-development project, it is even more important than usual that you get the maximum bang for your schedule buck. Best practices such as productivity offices, timebox development, accurate scheduling, and voluntary overtime help to make sure that you get as much work done each day as possible.
Lifecycle planning. One of the keys to targeting resources effectively is to apply them within a lifecycle framework that makes sense for your specific project. Without an overall lifecycle model, you can make decisions that are individually on target but collectively misdirected. A lifecycle model is useful because it describes a basic management plan. For example, if you have a risky project, a risk-oriented lifecycle model will suit you; and if you have vague requirements, an incremental lifecycle model may work best. Lifecycle models make it easy to identify and organize the many activities required by a software project so that you can do them with the utmost efficiency.
Customer orientation. One of the gestalt shifts between traditional, mainframe software development and more modern development styles has been the switch to a strong focus on customers' needs and desires. Developers have learned that developing software to specification is only half the job. The other half is helping the customer figure out what the product should be, and most of the time that requires an approach other than a traditional paper-specification approach. Putting yourself on the same side as the customer is one of the best ways to avoid the massive rework caused by the customer deciding that the product you just spent 12 months on is not the right product after all. The best practices of staged releases, evolutionary delivery, evolutionary prototyping, throwaway prototyping, and principled negotiation can all give you leverage in this area.
CROSS-REFERENCE
For more on customer orientation, see Chapter 10, Chapter 10.
The most tangible dimension of the people/process/product/technology compass is the product dimension, and a focus on product size and product characteristics presents enormous opportunities for schedule reduction. If you can reduce a product's feature set, you can reduce the product's schedule. If the feature set is flexible, you might be able to use the 80/20 rule and develop the 80 percent of the product that takes only 20 percent of the time. You can develop the other 20 percent later. If you can keep the product's look and feel, performance characteristics, and quality characteristics flexible, you can assemble the product from preexisting components and write a minimum amount of custom code. The exact amount of schedule reduction made possible by focusing on product size and product characteristics is limited only by your customer's product concept and your team's creativity.
Both product size and product characteristics offer opportunities to cut development time.
Product size. Product size is the largest single contributor to a development schedule. Large products take a long time. Smaller products take less time. Additional features require additional specification, design, construction, testing, and integration. They require additional coordination with other features, and they require that you coordinate other features with them. Because the effort required to build software increases disproportionately faster than the size of the software, a reduction in size will improve development speed disproportionately. Cutting the size of a medium-size program by one-half will typically cut the effort required by almost two-thirds.
CROSS-REFERENCE
For more on manipulating product size to support development speed, see Chapter 14, Chapter 14. For more on the effect that product size has on a development schedule, see Chapter 8, Chapter 8.
You can reduce product size outright by striving to develop only the most essential features, or you can reduce it temporarily by developing a product in stages. You can also reduce it by developing in a higher-level language or tool set so that each feature requires less code.
Product characteristics. Although not as influential as product size, other product characteristics do have an effect on software schedules. A product with ambitious goals for performance, memory use, robustness, and reliability will take longer to develop than a product without any goals for those characteristics. Choose your battles. If rapid development is truly top priority, don't shackle your developers by insisting on too many priorities at once.
CROSS-REFERENCE
For more on the effect that goals can have on a development schedule, see Goal setting in Using the Top Five Motivation Factors.
Changing from less effective tools to more effective tools can also be a fast way to improve your development speed. The change from low-level languages like assembler to high-level languages like C and Pascal was one of the most influential changes in software-development history. The current move toward componentware (VBXs and OCXs) might eventually produce similarly dramatic results. Choosing tools effectively and managing the risks involved are key aspects of a rapid-development initiative.
CROSS-REFERENCE
For more on productivity tools, see Chapter 15, Chapter 15.
There is a point at which your focus on people, process, product, and technology becomes synergistic. Neil Olsen conducted a study in which he found that going from low spending to medium spending on staffing, training, and work environment produced proportionate gains: additional spending was justified on roughly a 1-to-1 payback basis. But when spending on staffing, training, and work environment went from medium to high, productivity skyrocketed, paying back 2 to 1 or 3 to 1 (Olsen 1995).
Software-engineering practices can also be synergistic. For example, an organizationwide coding standard helps an individual project, but it also makes it easier for one project to reuse components from another project. At the same time, a reusable-components group can help to enforce a coding standard and ensure that it's meaningful across projects. Design and code reviews help to disseminate knowledge about both the coding standard and existing reusable components, and they promote the level of quality needed for reuse to succeed. Good practices tend to support one another.