The People Issue

Fact 1: The most important factor in software work is not the tools and techniques used by the programmers but rather the quality of the programmers themselves .

Fact 2: The best programmers are up to 28 times better than the worst programmers, according to individual differences research. Given that their pay is never commensurate, they are the biggest bargains in the software field.

”Robert L. Glass ^[3]

In his discussion of the foregoing facts, Glass notes that we have been aware of these human differences since 1968: ^[4]

Nearly everyone agrees, at a superficial level, that people trump tools, techniques, and process. And yet we keep behaving as if it were not true. Perhaps it s because people are a harder problem to address than tools, techniques, and process.

We in the software field, all of us technologists at heart, would prefer to invent new technologies to make our jobs easier. Even if we know, deep down inside, that the people issue is a more important one to work.

”Glass, 2003

This book is an attempt to address the people issue. Specifically , it is an attempt to help developers improve their intrinsic abilities .

The Need for Better Developers

For decades, the profession of software development has relied on an implicit promise: Better tools, methods , and processes will allow you to create superior software using average human resources. Managers have been sold the idea that their jobs will be made easier and less risky by adoption of strict formal methods and processes ”a kind of intellectual Taylorism. (Taylor, Gilbreth, and others advanced the concept of scientific management, time and motion studies, and the modern assembly line. Their distrust of human workers led them to the idea that imposed process and method could compensate for weaknesses they felt to be innate in workers. The same attitude and philosophy are assumed in the field of software engineering.) For the most part, these efforts have failed miserably.

Instances of success exist, of course. ^[5] You can find cases in which project A using method X did, in fact, achieve notable success, but industry statistics as a whole have failed to improve much since 1968, when software engineering and scientific management were introduced as means for resolving the software crisis. Abandoned projects, cost/time overruns, and bloated, buggy software still dominate the landscape.

Even the most ardent advocates of software engineering (for example, Dykstra, Boehm, and Parnas), as well as those most responsible for popularizing software engineering among the corporate masses (Yourdon and Martin), recognized the limits of formal approaches. In A Rational Design Process: How and Why to Fake It, ^[6] Parnas acknowledged the fact that highly skilled developers did not do development the way that so-called rational methods suggested they should. Martin suggested that the best way to obtain high-quality software ”software that met real business needs on time and within budget ”was the use of special SWAT teams comprising highly skilled and greatly rewarded developers doing their work with minimal managerial intervention.

The only consistently reliable approach to software development is, simply, good people. So why have so much attention and effort been devoted to process and method? There have been at least three contributing reasons:

A widespread belief, partially justified, that not enough good people were available to accomplish the amount of development that needed to be done.
An unspoken but just as widely held belief that really good developers were not to be trusted ”they could not be managed, they all seemed to be flaky to some degree, and they did not exhibit the loyalty to company and paycheck of normal employees . Really good developers tended to be artists , and art was (is) not a good word in the context of software development.
A suspicion, probably justified, that we did not (do not) know how to upgrade average developers to superior developers except by giving them lots of experience and hoping for the best.

It is no longer possible to believe that either method or process (or both together) is an adequate substitute for better people. There is a resurgence of interest ”spurred most recently by XP and the core practices in other agile methods ”in how to improve the human developer. This interest takes many forms, ranging from XP itself to redefinition of software development as a craft (McBreen ^[7] ) and a calling (West ^[8,] Denning ^[9] ) instead of a career to software apprenticeship (Auer ^[10] ). Why do we need better developers? Because increasing the supply of highly skilled people ”rather than only adhering to particular methods and processes ”is the only way to resolve the software crisis.

Note

Extreme programming and agile methods derive from the actual practice of software development rather than academic theory. The critical difference between XP/agile and traditional methods is their focus on attitudes, behaviors, culture, and adaptive heuristics instead of formal technique and theory. If the method label is to be attached to XP/agile, it should be in terms of a method for producing better developers rather than a method for producing better software. Better software comes from, and only from, better people.

Producing Better Developers

What makes a better developer? The traditional answer is experience. Most textbooks on software engineering and formal process contain a caveat to the effect that extensive real-world experience is required before the tools and techniques provided by method/process can be effectively utilized. In this context, experience is just a code word for those aspects of development ”philosophy, attitude, practices, mistakes, and even emotions ”that cannot be reduced to syntactic representation and cookbook formulation in a textbook .

Today s practitioners , and some theorists, are intensely interested in teasing apart and understanding the complex elements behind the label experience. There is great desire to understand what developers actually do as opposed to some a priori theory of what is appropriate for them to do. Models are seen as communication devices, unique to a community of human communicators , instead of vessels of objective truth with a value that transcends the context of their immediate use. Development is seen as a human activity ”hence a fallible activity ”that must accommodate and ameliorate imperfection and mistakes rather than seek to eliminate them. Communalism is valued over individualism . Systems are seen as complex instead of just complicated, necessitating a different approach and different insights than were required when software developers merely produced artifacts that met specification.

All of this intense interest is producing results. Although the total picture is still emerging, some facets of the better developer are coming into focus.

XP provides a foundation by identifying a set of discrete practices that can actually be practiced. Any developer can actually do these practices and, simply by doing them, become a better practitioner. They offer no grand theory, nor are they derived from any theory. The justification for the XP approach is based on two simple empirical observations: We have seen master developers do these things and We have seen less proficient developers do these things and become better. Although XP does make claims to improve both product and process, these are side effects ”one is tempted to say mere side effects ”of the improvement in the human developers.

XP/agile approaches provide a solid foundation, but just a foundation. What Xgilistas ^[11] do is but part of what makes them master developers. What they think and how they think are critically important as well. XP relies on maximized communication and storytelling as a means for enculturating new developers in appropriate ways of thinking. Thinking includes a value system, a history, a worldview , a set of ideas, and a context. And XP encompasses an oral tradition that has not, as yet, been reduced to ink and paper (and maybe cannot be so reduced). Aspiring Xgilistas must become conversant with all of this before they can attain true master status.

One component of the oral tradition, of the history, and of the common worldview is the use of object-oriented approaches to design and programming. Unfortunately, this is seldom made explicit in the XP literature. The terms object and object-oriented do not appear in any of the first five books in the Addison-Wesley XP series ”except once, and that occasion points to an incorrect page in the text. However, object vocabulary and concepts are abundantly evident. This discrepancy merely confirms that object thinking is presupposed by those advocating XP. The primary goal of this book is to provide one small contribution to help those following the Xgilista path ”specifically, a contribution in the area of object thinking .

^[3] Glass, Robert L., Facts and Fallacies of Software Engineering . Boston: Addison-Wesley, 2003.

^[4] Sackman, H., W.I. Erikson, and E.E. Grant. Exploratory Experimental Studies Comparing Online and Offline Programming Performances. Communications of the ACM , January 1968.

^[5] Some advocates of software engineering and process improvement will make claims of major successes (SEI Report CMU/SEI-2001-SR-014).

^[6] Parnas, David Lorge, and Paul C. Clements. A Rational Design Process: How and Why to Fake It. IEEE Transactions on Software Engineering . Vol. SE-12, No. 2, February 1986.

^[7] McBreen, Peter. Software Craftsmanship: The New Imperative . Boston: Addison-Wesley, 2001.

^[8,] West, David. Enculturating Extreme Programmers and Educating Xgilistas.

^[9] Denning, Peter. ACM editorial.

^[10] Ken Auer, www.rolemodelsoft.com .

^[11] A neologism ”useful for labeling those that embody one or more of the approaches that fall under the agile label.