Perceptions of XP

Students in the author's software engineering course work in small teams to develop the requirements for, to design, and to implement the first build of a project for an external client. A few projects are for clients outside the university, but most are sponsored by other faculty members.

In addition to the project, the students are required to complete two research/writing assignments during the semester. One of these is an opinion paper that is due near the end of the course. The opinion paper is always on a relevant topic that has not yet been covered in the course, to avoid influencing the results. By the time they write the paper, the students know that their opinions do not have to agree with the instructor's opinions, which removes a possible source of bias.

During the fall semester of 1999, all students were required to write an opinion paper that addressed the question "Should Extreme Programming be adopted as the life cycle model for the project portion of this course?" During the fall semester of 2000, the students were given a choice of topics, including the same question about Extreme Programming. The students were given a few references as a starting point and were required to include additional references in their papers.

The numbers and reasons that follow must be viewed in light of the characteristics of the students as they pertain to this topic. This was the first time that most of the students had studied team dynamics and software life cycle concepts. Students entering this course had no prior instruction in systems analysis, software design, or software engineering. Fewer than 25% of them had had an internship or significant industrial experience. Although all the students had been required to work in small informal groups to complete major projects in other courses, this was the first time that they had worked with a client other than the instructor for the course.

The results were consistent across the two semesters. Of the 40 students who addressed this question, 14 (35%) were in favor of adopting XP and 26 (65%) were opposed. Although there was little support for using XP on the project, there was very strong sentiment for studying XP as an alternate life cycle model. The numbers are interesting, but the reasons for the opinions are more enlightening.

Support for Extreme Programming

The primary reasons that were given to support using XP as the life cycle model for the project in software engineering can be organized into four categories: (1) progress is more visible, (2) communication within the project is improved, (3) complexity is easier to manage, and (4) testing is improved. Each of these reasons is discussed later in this chapter.

Most of the proponents cited visible progress as a major justification for using XP in the project. One student wrote:

Students are used to being able to see progress when working on a project. Extreme Programming allows the student to produce a program a little at a time. By seeing this progress, the students will feel more comfortable with the process.

Another wrote:

If XP were used, we could develop less paperwork in the beginning so we could start writing code. It is much easier to see progress when you can use something that you can see work.

As indicated by the preceding two statements and other similar responses, students have learned to equate progress with functioning code. Extreme Programming is a better match for their perception of progress.

A few students included improved communication among their reasons for using Extreme Programming. Although most of these comments appear to have been motivated by problems with individual project teams, one student added a new insight.

XP keeps the clients continuously in contact with the teams during the process and included in all of the decisions that are made in the project. This gives the students the opportunity to build on their interview skills.

The statements pertaining to reduced complexity focused on the small size of each build. These comments were from members of teams who failed to manage the complexity of their projects.

Some students mentioned the testing aspects of Extreme Programming. The most compelling statement was made by a student who wrote:

Generally, testing is not emphasized strongly in the college curriculum and yet it is so very important in the real world. An XP approach would give students an opportunity to develop the skills for designing and running thorough tests.

Opposition to Extreme Programming

The students had several reasons for not adopting XP. These reasons fall into five major categories: (1) narrowing of the course content, (2) inadequate preparation for XP, (3) scheduling conflicts, (4) insufficient estimation skills, and (5) unrealistic cycle times.

The most persistent and compelling arguments against the use of Extreme Programming were based on course content. The students felt that they needed to understand the issues and processes associated with requirements elicitation, systems analysis, and software design before they began to use Extreme Programming. The following four quotes demonstrate the students' thinking.

XP isn't for beginners. It assumes that the developers already know the tricks of the trade concerning design and that they know their own abilities.

Students entering the class have little knowledge of developing software and need to learn about requirements, specification, design, implementation, and integration. The best way to learn these different steps is to do them, so XP wouldn't be the best choice, because the XP model doesn't seem to be concerned with any division of these steps.

One of the other life cycle models is perhaps better because they work slowly through the specification and design phase, allowing for developers to learn the importance of documentation and global thinking about a software system.

The process of XP requires some prior knowledge of software development life cycles to fully understand the concept behind it and why it would be useful.

The students that mentioned scheduling conflicts approached the issue from two perspectives. Some pointed out that modern students must divide their time between course work and other obligations, such as work and family. Others mentioned difficulties in scheduling frequent sessions with the clients, who have their own agendas. One student captured the essence of this problem by writing:

The chances that software engineering students can work on their individual portion of the project every day are very slim. Instead of a workplace environment with focus on only those projects, the students have other obligations along with their multiple classes.

A few students were concerned about other issues. Some mentioned that they lacked the experience to make accurate time estimates as required by XP. In a related theme, some were concerned about the short cycle times for each build. In both cases, the primary concern seemed to be a perception of decreased quality. This concern was expressed well by the student who wrote:

As a result of prior programming classes, students will have more than likely adopted the build-and-fix method of developing software. This is fine when the projects are small, but in a large project and without self-discipline, the "iteration process" of XP could quickly degrade into the build-and-fix model as students feel the need to hurry up and finish.