- 1.1 Software Crisis
- 1.2 People Impact on Productivity
- 1.3 Agile Contributions to Development Productivity
- 1.4 Magic Bullets
- 1.5 Development Constraints
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 People Impact on Productivity
All organizations and development methods can be represented by the People-Process-Project triad shown in Figure 1.4. The projects vary from industry to industry with the products of each industry contained in the Project terminal. All organizations contain a People terminal representing the physical environments the people are part of and the management environments of those individuals. The Process terminal in the triad represents the development processes used by the people to produce the organization’s products. Organizational capability and development productivity are largely driven by the communication and management attributes of the People terminal in the triad model.
The Process terminal determines the process used to develop the organization products. For the purpose of this text I am going to divide the processes into two camps. The first camp I will refer to as the “traditional” processes. The traditional processes include the classic waterfall and spiral14 development and other variations of the waterfall process. The core of the spiral is also a waterfall process. The second camp, which I will refer to as “Agile,” comprises the varied Agile software development processes. Agile methodologies include pair programming15 (1975), Scrum16 (1995), Crystal Clear17 (1996), Extreme Programming18 (1996), Adaptive Software Development,19 and the Dynamic Systems Development Method (DSDM)20 (1995) among others.
This text is not going to describe in detail or advocate any of the methods in either of the two camps, but concentrates on the People terminal and its impact on software development productivity.
Until the mid-1970s people were the most ignored part of the triad. The People terminal is common to both the traditional and Agile process camps. For example, pair programming, an Agile method, is very dependent on communications and management support to function, and the pair programming concept works well in the traditional environment.
I have separated the People terminal and added the communications and management connectors to emphasize their significance in the model. Barry Boehm wrote in 1981:
Poor management can increase software costs more rapidly than any other factor. Each of the following mismanagement actions has often been responsible for doubling software development costs. . . .21
Of course, you have to read the first 485 pages of his book to find this simple yet profound statement. Most readers don’t seem to read that far. Weinberg’s Second Law of Consulting22 added a supporting observation:
No matter how it looks at first, it’s always a people problem.
Gerry Weinberg23 derived a comparison of the relative impact of the development environment to cost and productivity from Barry Boehm’s classic study of software engineering economics.24 Boehm isolated a group of 16 “cost drivers” that determined the cost impact of each driver on the software product. Weinberg grouped the cost drivers into four categories—tools, people, systems, and management—according to the Boehm cost-driver definitions. The results, which should point to the group with the highest payoff, are plotted in Figure 1.5 according to the percentage of total cost.
)
Figure 1.4 Software development triad: People-Process-Project
)
Figure 1.5 Relative impact of four categories of software cost drivers according to the Boehm software engineering economics study
Source: G. Weinberg, Quality Software Management, Volume 3
)
Figure 1.6 Number of publications compared with Weinberg’s relative productivity impact
Source: G. Weinberg, Quality Software Management, Volume 3
Figure 1.625 illustrates the vigor with which the Software Engineering Institute research has pursued a technology solution (a silver bullet) to the productivity problem, according to the number of papers published in the areas defined by Weinberg between 1986 and 1991. The key to increased productivity doesn’t appear to be technology.
Weinberg demonstrates the results of this research by comparing the relative percentages of Software Engineering Institute publications in major activity areas of technology (tools), people (education), systems (development environments), and management with the relative productivity gain for each group. According to Weinberg, the most significant productivity improvement area is, by far, the management activity area.
Barry Boehm argued, “Poor management can increase software costs more rapidly than any other factor.” But he explains his omission of management as a cost driver in the following:26
- Despite this variation, COCOMO does not include a factor for management quality, but instead provides estimates which assume that the project will be well-managed.
The well-managed concept does not work in this context. Boehm’s analyst and programmer capability-rating definitions evaluate the environment independent of management. Without management factors, we cannot distinguish between well-managed and poorly managed projects, nor can we consider the implication of communications and organizational culture on productivity.
The software management problem, including cost and schedule estimating and their optimistic approaches, can be described by the following statement made by Fred Brooks in The Mythical Man-Month (1975), which sums up some of the major difficulties of traditional project management:
- More software projects have gone awry for lack of calendar time than for all other causes combined. Why is this cause of disaster so common?
- First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well.
- Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.
- Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine’s chef.
- Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.
- Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. “Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline and thus begins a regenerative cycle that ends in disaster.”27
The fifth cause listed by Brooks is almost universally experienced today (al-most 40 years later) in traditional software development. It is obviously a bad approach to solving the schedule slippage problem, but it is normally the first solution choice applied without reasonable judgment. At least cost and schedule estimating is much better than at the time of Brooks’ assessment. Optimism is still widely used as a management tool.