Exploring Extreme Programming for Scientific Research

Author(s): Wood, W.A., Kleb, W.L.
Venue: Software, IEEE
Date: May-Jun 2003

Type of Experiement: Case Study
Sample Size: 2

Quality
3

Reference: http://mythic.lib.calpoly.edu:2388/iel5/52/26915/01196317.pdf?tp=&arnumb...

SUMMARY
Exploring Extreme Programming for Scientific Research recounts the culture conflicts brought upon by adopting extreme programming in a group of two developers writing codes for aerothermal predictions on nosecones of hypervelocity vehicles. The Langley Creativity and Innovation Office solicited bids for exploring nontraditional methodologies for aerospace engineering research, trying to produce extraordinary gains in productivity. The author and his collaborator submitted a bid to The Langley Creativity and Innovation Office, proposing a short prototyping assessment of extreme programming at the NASA Langley Research Center, and the bid was granted.

The project used Linux operating systems, the Emacs integrated development environment, and the Ruby programming language. Although both programmers on the team had over 20 years of prior experience each, they had no experience in team software development, object-oriented design, unit testing, or programming with Ruby.

The notions of traditional software engineering for the team had to be reworked, and several traditional cultural barriers had to be overcome. The team had to do away with up-front design, and had to eliminate big specifications. The two programmers also had to learn to “guess” the time for tasks, and had to relinquish sole code ownership and adopt a code-based owned to no one individual, but the entire team. Since the team was only comprised of two programmers, during paired programming sessions, to “rein in cowboy coding”, the pair used test-driven pair programming exclusively when implementing features. The team noted that they preferred pair programming during refactoring but allowed solo refactoring when scheduling conflicts precluded pairing, without adding any additional functionality and keeping all tests intact. Getting used to the short iteration schedule also was a challenge, but when the office was rearranged, communication and productivity seemed to increase.

Overall, eight of the twelve practices of extreme programming presented implementation challenges, yet only the 40-hour-week practice seemed to hinder the team on some level, mainly due to lack of time and conflicting schedules. Since the team was writing code for its own use, and the project funder was too far removed from the research to serve as a suitable customer, the team acted as their own customer. Although not the traditional implementation of the on-site customer extreme programming practice, the team asserted that trying to view the project from a user-oriented perspective did help focus research effort, and playing the role of “customer” during the planning game improved the research project’s value.

The study concludes with several reports based on gathered data, and a few recommendations. For one, the author and his colleague recommend a planning game with a customer role for research projects as an effective focusing tool, even if extreme programming as a whole is not adopted. Paired programming led to intense sessions that discouraged cutting corners, and the constant code review produced cleaner, more readable code that was much easier to modify and extend. The team produced 2,545 lines of Ruby code for an average of 27 lines per hour as a pair, instead of individually at 12 lines per hour (24 per hour as a pair), but this was not experimentally tested. While lines per hour seemed to increase, the number of overly-verbose lines of code reduced due to “merciless” refactoring, the concisely expressive nature of Ruby, and the continuous code reviews “inherent” in paired programming.

The results from this study indicate that the extreme programming approach to software development is approximately twice as productive as similar historical projects that the team had undertaken. The functional code base is about half as many lines of code as expected, and the code’s readability was much improved. The extreme programming practices of continual refactoring, simple design, and constant code review are pegged as the largest contributors to the improved code aesthetics.

0