Although it is not very evident in much of the Java-centric literature that surrounds XP, it owes most of its heritage to ideas from the Smalltalk world. Even in the 1980s, Smalltalk had powerful, expressive class libraries and a forgiving, flexible, powerful, and productive development environment. The Smalltalk environment encourages developers to be fearless because it is so forgiving. It really encourages incremental design and development because you know there is no way that you can “paint yourself into a corner.”

In sharp contrast to this, I distinctly remember trying to get stuff right the first time when working in C++ in the early 1990s because it was such a pain to change things later. Renaming methods and classes to make them more expressive was not something we consciously thought of because it was so hard to do.

Although XP has grown beyond its roots in the Smalltalk culture, it still embodies the idea that, given good tools, programs are easy to change and that applications can be understood by reading the source code. This is in sharp contrast to the traditional software development experience that programs are notorious hard to change and the code is so convoluted that separate documentation is necessary to make any sense of the application.

— Pete McBreen, Questioning Extreme Programming, Chapter 2

Although opponents of Extreme Programming are always asking for studies about the effectiveness of XP, it is interesting to note that there are no real studies that support any methodology. There are no comparative studies that have ever taken place on reasonable-size projects. Indeed, it is hard to trust any of the studies in the software engineering field because they were either carried out a long time ago or because the numbers come from a small study that lasted a few weeks.

Studies that were carried out more than ten years ago are suspect because of the dramatic improvements in hardware and software tools over the years. Personally, I find that object-oriented programming at an interactive workstation is qualitatively different from the old days of batch compiles in low-level languages, when we were lucky to get three or four compilation runs a day.

Small short-duration studies are suspect because they are dominated by short-term learning effects, mostly because they are constrained to using novices. This is a problem because novices use different strategies than experts, and when experts switch to a new way of working, they experience a larger drop in performance than novices. These two factors make it dangerous to extrapolate long-term expert performance from that of novices.

— Pete McBreen, Questioning Extreme Programming, Chapter 1

Many employers find that graduates and sandwich students come to them poorly prepared for the every day problems encountered at the workplace. Although many university students undertake team projects at their institutions, an education environment has limitations that prevent the participants experiencing the full range of problems encountered in the real world. To overcome this, action was taken on courses at the Plessey Telecommunications company and Loughborough University to disrupt the students’ software development progress. These actions appear mean and vindictive, and are labeled ‘dirty tricks’ in this paper, but their value has been appreciated by both the students and their employers:

1. Give an Inadequate Specification
2. Make Sure All Assumptions are Wrong
3. Change the Requirements and Priorities
4. Present an Uncertain and Naive Customer
5. Have Conflicting Requirements and Pressures
6. Present Customers with Conflicting Ideas
7. Present Customers with Different Personalities
8. Ban Overtime
9. Give Additional Tasks to Disrupt the Schedule
10. Change the Deadlines
11. Introduce Quality Inspections
12. Present a ‘Different Truth’
13. Change the Team
14. Change the Working Procedures
15. Upgrade the Software
16. Change the Hardware
17. Crash the Hardware
18. Slow the Software
19. Disrupt the File Store
20. Say “I Told You So!”

— Ray Dawson, Proceedings of the 22nd International Conference on Software engineering

Traditionally, leadership is conceptualized as a special form of power relationship where leaders have substantial influence over the behaviour of followers and exercise that power for mutual benefit. With geekwork, you are attempting to harness the creativity of individuals and groups in its purest form. And although behaviour plays a role, it is substantially less important than in almost any other form of work.

Because power is about the regulation of behaviour, it has very little effect on creativity. Traditional methods of exercising control have very little positive effect on the inner state of mind of geeks. And so power itself becomes substantially less important a facet of the relationship between leaders and geeks.

We must rethink what it means to lead in the face of geekwork because most conceptions of leadership are intimately tied to notions of power.

— Paul Glen, Leading Geeks, Chapter 1

Why are there so many different correct approaches to designing the solution to a problem? Because the solution space is so complex.

Why is estimation so difficult? Because our solutions are so much more complicated than our problems appear to be.

Why is reuse-in-the-large so elusive? Because complexity magnifies the solution diversity that limits the value of large-scale reuse.

Why do top people matter? Because it takes considerable intelligence and skill to overcome complexity.

Why do the best designers use iterative, heuristic approaches? Because there are seldom any simple and obvious design solutions, and even more seldom any optimum ones.

Why is software maintenance such a time consumer? Because it is seldom possible to determine, at the outset, all the ramifications of a problem solution.

Why does software have so many errors? Because it is so difficult to get it right the first – of even the Nth time.

Complexity, I would assert, is the biggest factor involved in anything having to do with the software field. It is explosive, far reaching, and massive in its scope.

— Robert L Glass, Communications of the ACM, November 2002

All available research indicates that the ability of a manger to predict how a future employee will perform, based upon a one hour interview, is very low. Yet most managers have great confidence in their predictive ability based upon impressions formed in a brief interview.

There appear to be two main reasons for this mismatch of effectiveness. First, interviewees tend to give sociably desirable answers to the interviewer. Second, the interviewer’s biases are formed by a poor research methodology. Assume an interviewer interviews five people for a high-scope job. After interviewing each candidate, the interviewer selects the person who was rated the highest. This person joins the company and is an above-average employee for the next two or three years. The interviewer’s impressions about his predictive ability are reinforced because he sees the positive results of his interview. What the interviewer doesn’t know is how the other four would have performed. They may even be superior to the person hired.

— Robert A. Zawacki, “How To Pick Eagles”, Datamation, September 15, 1985.

Endless books and articles have been written about how to select the right employee for the job or the team, with principles, guidelines, and checklists galore. Many of these are quite helpful, but they do tend to give the fairy-tale impression that if you choose the right princess and the right frog, they will live happily ever after. Whatever else it does, this model makes managers over-anxious about selecting people for teams, and under-anxious about exercising their control function throughout the life of those teams.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 21

Managers make two kinds of mistakes concerning the amount of control they exert over internal team affairs: too much or too little. Variable (Pattern 1) managers tend to intervene too little, placating the team.

Routine (Pattern 2) managers tend to overcorrect by intervening too much and blaming the team. For effective steering (as in a Pattern 3 organization) manager’s interventions or non-interventions into team affairs must be done on the basis of what the team is doing, not what the manager is feeling.

When choosing interventions, a good guide is the MOI model. This model says that when a team or individual isn’t functioning well, there may be a missing ingredient. It could be Motivation, Organization, or Information. Your job is to find out which and intervene accordingly.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 20

One of the arguments against reusable software is that it doesn’t come free. We cannot reuse just any old software that’s been slapped together; we must make an additional investment to render it truly reusable. The higher that investment, the more times we must reuse the module to recoup the investment.

A similar argument is often made against using teams for software development and maintenance. Teams do require a startup cost, and in many projects this startup is so long we never recover the cost during the life of the project. This argument, however, is not against the use of teams, but in favour of better management of team formation.

Even if management were poor, the cost of team startup could be recovered by reusing the teams over a series of projects. Unfortunately, only the better software organizations seem to reuse their teams. Given that breaking up successful teams is economic nonsense, why is it so common? Long before the days of software, people understood that the practice of dissolving well-functioning teams ultimately derives from insecure management.

Isn’t it time that your software organization woke up? Just as reusable components are the basic units in hardware and software development, the software team is the basic design unit for software engineering processes. The job of the manager is to create, nurture, and maintain the teams that can be configured and reconfigured into reliable, predictable projects. Without such teams, no software organization can ever emerge from a Variable (Pattern 1) or Routine (Pattern 2) culture.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 19

All temperaments find teamwork satisfying, but each for a different reason. The NT Visionaries, for instance, find great satisfaction in the quality that a team can produce. The SJ Organizers especially like the efficiency of well-functioning teams, while the SP Troubleshooters really enjoy the team as a crisis management tool. The NF Catalysts particularly like teams. They appreciate the communication, excitement, and hope generated by teamwork, and they especially like the way the team fosters the growth of its members. Sometimes, it’s critical to reduce the elapsed time to locate the fault behind certain failures. In such cases, the manager can create parallel teams working to locate the same fault.

It’s quite easy to predict the reactions of each temperament to this suggestion. NF Catalysts may resist because they fear that the “losing” teams may be embarrassed. SJ Organizers are concerned with the inefficiency of two or more teams working on the same problem. NT Visionaries sometimes feel that the “best” team ought to be left to do the job alone. SP Troubleshooters, however, seem to relish the idea of making a game out of work.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 18