Exploring XP for Scientific Research

Chien-Tsun ChenAug 12, 2003

ctchen@ctchen.idv.tw

ReferencesW. A. Wood and W. L. Kleb, Exploring XP for Scientific Research, IEEE Software, May/June 2003.K. Beck, Extreme Programming Explained, Addison Wesley, 1999.

OutlineIntroductionWhen You Should Not Try XPImplementing XP PracticesConclusion

Introduction

Background (1/2)The authors are researchers in the NASA Langley Research Center.

W. A. Wood received his PhD in aerospace engineering form Virginia Tech.W. L. Kleb is a PhD candidate in aerospace engineering at the University of Michigan.Both of them have over 20 years programming experience.

The Langley Creativity and Innovation Office solicited bids for exploring nontraditional methodologies for aerospace engineering research.The authors submitted a bid and received one-year funding to perform a short prototyping assessment of XP.

Background (2/2)

Development environment:GUN/Linux.Emacs.Ruby.

The authors had experience in Fortran programming but no experience in team software development, OOD, unit testing, and programming with Ruby.

When You Should Not Try XP(Business) Cultural Conflicts

Insist on complete up-front design.Big Specifications.Really smart programmers.Team size.A long time to gain feedback.Wrong physical environment.

People are required to put in long hours to prove their commitment to the company.Single-threaded integration process.Inherently exponential cost curve.A baby screaming in the room.

Implementing XP Practices

The XP Practices [Beck]

Experience With XP Practices

(40-hour week)

(Testing)

Implementation Challenges

On-site customer.Simple design.Pair programming.Collective ownership.Sustainable pace.Test-driven development.Metaphor.Continuous integration.

Results

I 1.1 I 1.2 I 1.3 I 2.1 I 2.2 I 2.3

Release 1 Release 2

two-week iteration

6 weeks 6 weeks

S(48)

S(38)

S(54)

S(56) (7.8 hours/week)

(1.75) (1.875)(0.86) (1.085)

?

The times don’t include time spent on the planning game (two hours at the start of each iteration)

2545 lines of Ruby code (in pair)

27 lines/hour

One method with an associated test containing five asserts every 45 minutes (includes design, integrate, refactoring, test, and debugging).Compare with prior projects:

12 lines/hors, or 24 lines/hour for two workers (27 vs. 24).But not including testing.

A prior, non-XP project with comparable functionality:2144 lines (912 vs. 2144)

Refactoring, Ruby and continuous code review.

XP approach to software development is approximately twiceas productive as similar historical project.

ConclusionItems Historical

Projects This (XP) Project

Production code (line/hour)

1 (24) 1 (27)

Production code (lines)

2 (2144) 1 (912)

Test code 0 1 (1135)

Readability N/A Improved

Q&A

Insist On Complete Up-front Design

In Feb 2002, NASA announced a 23.3 million award to Carnegie Mellon University “to improve NASA’s capability to create dependable software”

Two-week training courses in the Software Engineering Institute’s Team and Personal Software Processes (TSP & PSP) have begun, complete with 750 pages of introductory textbooks.The TSP assigns two-thirds of the project time to requirements gathering, documenting, and design. It does not allow coding until the final third of the project.

Break the rules.

Big SpecificationsLangley’s ISO 9001 implementation includes a 45-page flowchart for software quality assurance (LMS-CP-4754) and a 17-page flowchart for software planning and development (LMS-CP-5528).

Break the rules.

Really Smart ProgrammersThe researchers typically have doctoral degrees, andThe reward structure under which they operate is based on peer review of the person’s stature in the field.

Authors had to suppress their desire to be recognized for solo achievement and believe that two people doing XP would be more productive than the sum of their individual efforts.

Team SizeAlthough adopting XP for large teams has been a frequent subject of debates, authors faced the opposite problem-a small team of only two people.Maintaining the distinct roles of programmer, customer, recorder, and coach was challenging.

diligence in delineating roles and a conscious decision to stay focused on productive work.

A Long Time To Gain FeedbackOne role of a government research center is to pursue long-term, revolutionary projects. Development cycles can last a decade, and the feedback loop on.whether the project is headed in a fruitful direction is often measured in years.Authors did not know if they could recast long-term research goals into small, tangible increments suitable to XP’s two-to-three-week iteration cycles.

Although the research feedback timescale remains large, authors successfully decomposed the technical features into small iteration chunks by following XP’s simple design practice.

Wrong Physical EnvironmentThe problem of “senior people with corner offices”.

Authors refactored their office cubical layout into a commons and alcoves development room, with copious marker board space and a pair programming station.

Office Layout Refactoring

15‘ x 17’ office layout

The Pair Programming Station

2560 x 1024

The station had simultaneous dual keyboard and mouse inputs connected to a 16-processor Beowulf cluster.

The C3 Work Area [Beck]

On-site CustomerIn the context of long-term research, the researcher is essentially the “customer” for his own development effort-at least for several years.

Authors were primarily writing software for their own use.There are only two members in this project.

Switching roles.The customer had to remain focused on end results rather than think of the developer’s work.

Even outside the context of XP, authors recommend a planning game with a customer role for other research projects as an effective focusing tool.

Pair ProgrammingProblem:

It seemed a small team would suffer from not being able to rotate pairs.

However, authors actually achieved productivity gains through pairing:

The pair pressure effect led to intense sessions that discouraged cutting corners.Constant code review produced cleaner, more readable code that ware much easier to modify and extend.They learned from each other of some tricks and tips that accelerated individual coding rates.

Collective OwnershipProblems:

Conflicted with authors established practices in the field and conflicted with the promotion criteria.They did not know the long-term impact of not having sole cold ownership with regard to promotion potential.

Authors anticipate that the more prolific research output enabled by XP will more than compensate for the loss of single code ownership in terms of profesional prestige.

Test-driven DevelopmentAuthors implemented four levels of fully automated testing:

Unit tests for each class.Collection of all unit tests.Smoke tests.Full stress tests.

Question: What is test-driven development really means?

MetaphorAuthors selected the naive metaphor.What is the naive metaphor?

… there is also a metaphor known as the naive metaphor which is based on your domain itself. But don't choose the naive metaphor unless it is simple enough. (http://www.extremeprogramming.org/rules/metaphor.html)

Continuous IntegrationProblems:

Continuous integration conflicted with the traditional approach of implementing algorithms in large chunks.

Authors’ solutions:By assembling a dedicated integration machine and by crafting scripts to automate development and testing tasks.The planning game and simple design helped pare implementations down to small chunks suitable for frequent integration.

Alcove [C. Alexander, A Pattern Language]