One of the philosophies undergirding this book is that it is better to make trade-off decisions with your eyes open than closed. If development speed is truly your top priority, then go ahead and increase the cost of the project and compromise the product's feature set in order to deliver it on time. But understand the implications of the decisions you make. Don't close your eyes and hope that somehow you'll be able to optimize your project for schedule, cost, and features all at the same time. You won't. Instead, you'll end up optimizing it for none of them; you'll waste time and money and deliver a product with less functionality than you otherwise could have.
With rare exceptions, initial resource estimates and schedules are unacceptable. This is not because the programmers are unresponsive, but because the users generally want more than they can afford. If the job doesn't fit the available schedule and resources, it must either be pared down or the time and resources increased. | ||
| --Watts Humphrey | ||
A trade-off triangle with schedule, cost, and quality at its corners is a general management fundamental. In software, however, having a "quality" corner on a trade-off triangle doesn't make much sense. A focus on some kinds of quality reduces cost and schedule, and on other kinds increases them. In the software arena, a better way to think of trade-offs is among schedule, cost, and product. The product corner includes quality and all other product-related attributes including features, complexity, usability, modifiability, maintainability, defect rate, and so on. Figure 6-10 illustrates the software trade-off triangle.
Figure 6-10. Software trade-off triangle. You have to keep schedule, cost, and product in balance for the project to succeed.
To keep the triangle balanced, you have to balance schedule, cost, and product. If you want to load up the product corner of the triangle, you also have to load up cost or schedule or both. The same goes for the other combinations. If you want to change one of the corners of the triangle, you have to change at least one of the others to keep it in balance.
To help me think about which option to manipulate, during planning discussions I like to visualize a large cardboard triangle with the corners labeled "schedule," "cost," and "product." The customers hold the corner or corners that they want to control. Our job as software developers is to let customers show us which corners they are holding and then to tell them what has to be done to balance the triangle. If a customer is holding the "product" and "cost" corners, we tell them what the "schedule" corner has to be. If they are holding only the "product" corner, we can give them a variety of cost-and-schedule combinations. But we developers absolutely must have at least one corner to hold on to. If your customer won't give you a corner of the triangle, you usually can't do the project.
Jim McCarthy reports that in informal polling he has found that about 30 to 40 percent of all development projects suffer from simultaneously dictated features, resources, and schedules (McCarthy 1995). If schedule, cost, and product aren't initially in balance—and they rarely are—that suggests that 30 to 40 percent of all development projects start out with no ability to balance their project characteristics for success. When a customer hands you a product definition, a fixed cost, and a fixed schedule, they are usually trying to put a 10-pound product into a 5-pound sack. You can try to force the 10-pounder into the sack, stretch the sack, and tear the sack, but in the end all you'll do is wear yourself out—because it just won't fit. And you'll still have to decide whether you want to get a bigger sack or put less into the sack you have.
CROSS-REFERENCE
For more on negotiating in difficult environments, see Beating Schedule Pressure, Beating Schedule Pressure.
Software products have two kinds of quality, which affect the schedule in different ways. One kind of quality is a low defect rate. To a point, low defects and short development times go together, so there is no way to trade off that kind of quality for schedule. The road to the shortest possible schedule lies in getting the product right the first time so that you don't waste time reworking design and code.
CROSS-REFERENCE
For details on the relationship between defect rate and development time, see Quality-Assurance Fundamentals, Quality-Assurance Fundamentals.
The other kind of quality includes all the other characteristics that you think of when you think of a high-quality software product—usability, efficiency, robustness, and so on. Attention to this kind of quality lengthens the development schedule, so there is an opportunity for trading off this kind of quality against the schedule.
CROSS-REFERENCE
For details on how to use this kind of quality to reduce development time, see Chapter 14, Chapter 14.
Is there a conflict between trying to achieve the greatest per-person productivity and the greatest schedule efficiency? Yes, there is. The easiest way to maximize per-person productivity is to keep the team size small. One of the easiest ways to shorten a software schedule is to increase team size, which increases total productivity but usually makes each person less efficient. Rapid development isn't always efficient.