Exploring XP for Scientific Research

focusExtreme Programming Exploring XP for Scientific Research William A. Wood and William L. Kleb, NASA Langley Research Center xtreme Programming, as an agile programming methodology, focuses on delivering business value. In the realm of exploratory, long-term, small-scale research projects, prioritizing near-term E tasks relative to their business or scientific value can be difficult. Assigning even a qualitative monetary value can be particularly challenging for government research in enabling fields for which business markets have not yet developed. The conflict between near-term value and long-term research objectives leads to a culture clash when apply- the project using a GNU/Linux operating sys- ing basic XP practices. tem, the Emacs integrated development environ- We decided to explore this culture clash ment, and the Ruby programming language.1,2 when the Langley Creativity and Innovation Of- We had prior experience programming related fice solicited bids for exploring nontraditional algorithms for the advection-diffusion equation methodologies for aerospace engineering re- using Fortran but no experience in team soft- search. C&I was looking for a way to produce ware development, object-oriented design, extraordinary gains in productivity or enable unit testing, or programming with Ruby. entirely new applications. We submitted a bid As the project began, we realized that we and received one-year funding to perform a first had to deal with several cultural conflicts short prototyping assessment of XP at the before implementing the 12 XP practices. NASA Langley Research Center. We conducted Cultural conflicts Kent Beck lists nine environments that he says don’t work well with XP.3 Six of these Eight of Extreme Programming’s 12 practices are seemingly nine are counter to the existing culture at Lan- incompatible with the existing research culture. However, despite gley. However, Beck prefaces his assertions initial awkwardness, the authors successfully implemented an XP with the caveat that the list is based on his per- prototype-assessment project at the NASA Langley Research Center. sonal experiences: “I haven’t ever built missile 30 IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/03/$17.00 © 2003 IEEE nosecone software, so I don’t know what it is Our Software Product like. … If you write missile nosecone software, you can decide for yourself whether XP might The research value we aimed to deliver was a software test bed for eval- or might not work.” The software we were de- uating the performance of a numerical scheme to solve a model advection- veloping was intended for aerothermal predic- diffusion problem. The model employs a multistage Runge-Kutta strategy for tions on nosecones of hypervelocity vehicles temporal evolution with multigrid sequencing. The particular algorithmic re- (see the “Our Software Product” sidebar), so search feature is a strategy for the pointwise optimization of the Runge- we set out to decide for ourselves if XP could Kutta coefficients to achieve particular damping characteristics as a tool for work in such a research-oriented environment. convergence acceleration.1 For more information on the actual software Here, we detail the six counter environments product,2 contact the authors. as they apply to our project. First, according to Beck, the “biggest barrier 1. W.L. Kleb, W.A. Wood, and B. van Leer, Efficient Multi-Stage Time Marching for Viscous to the success of an XP project” arises from an Flows via Local Preconditioning, Paper 99–3267, Am. Inst. Aeronautics and Astronautics, 1999. insistence on complete up-front design rather 2. W.A. Wood and W.L. Kleb, “Runge-Kutta Circular Advection Problem Solver,” NASA Tech than just steering the project along the way. In Briefs, vol. 26, no. 12, 2002, p. 38. February 2002, NASA announced a $23.3 mil- lion award to Carnegie Mellon University “to improve NASA’s capability to create depend- able software.” Two-week training courses in sire to be recognized for solo achievement and the Software Engineering Institute’s Team and believe that two people doing XP would be Personal Software Processes have already be- more productive than the sum of our individ- gun, complete with 750 pages of introductory ual efforts. textbooks. The TSP assigns two-thirds of the Fourth, although adopting XP for large project time to requirements gathering, docu- teams has been a frequent subject of debate, menting, and design. It does not allow coding, we faced the opposite problem—a small team with the possibility for steering, until the final of only two people. Maintaining the distinct third of the project. Furthermore, significant roles of programmer, customer, recorder, and steering can trigger a “relaunch,” in which you coach was challenging. With very small teams, start the requirements and design processes all the literature was unclear as to which tasks we over again. We used XP exclusively, avoiding could safely perform solo and which would the institutional bias toward the PSP and TSP. rapidly degenerate into cowboy coding. In ad- The second cultural practice at odds with dition, with only two developers, we couldn’t XP is big specifications. Langley’s ISO 9001 have the cross-fertilization benefit of rotating implementation includes a 45-page flowchart partners. Plus, interpersonal conflicts were a for software quality assurance (LMS-CP-4754) potential problem—if communication turned and a 17-page flowchart for software planning to confrontation, there were no other team and development (LMS-CP-5528), in which members to play the role of mediator. Ad- only one of the 48 boxes, located 75 percent of dressing these concerns required diligence in the way through, contains “Code and Test.” delineating roles and a conscious decision to At the risk of being ISO noncompliant, we ig- stay focused on productive work. To rein in nored the approved software process, deferring cowboy coding, we used test-driven pair pro- the issue to when, or if, an ISO audit uncovers gramming exclusively when implementing fea- the discrepancy. tures. We also preferred pair programming Third, Beck observes that “Really smart during refactoring but allowed solo refactor- programmers sometimes have a hard time ing when scheduling conflicts precluded pair- with XP” because they tend to “have the hard- ing. However, we agreed not to break any ex- est time trading the ‘Guess Right’ game for isting tests or add any functionality. close communication.” Not only do re- Fifth, according to Beck, “Another technol- searchers typically have doctoral degrees, but ogy barrier to XP is an environment where a the reward structure under which they operate long time is needed to gain feedback.” One is based on peer review of the person’s stature role of a government research center is to pur- in the field. The Research Grade Evaluation sue long-term, revolutionary projects. Devel- Guide4 emphasizes individual stature over opment cycles can last a decade, and the feed- team membership. We had to suppress our de- back loop on whether the project is headed in May/June 2003 IEEE SOFTWARE 31 increments suitable to XP’s two-to-three-week iteration cycles. Fortunately, in practice, although the research feedback timescale re- mains large, we successfully decomposed the technical features into small iteration chunks by following XP’s simple design practice. Finally, Beck cautions against “senior people with corner offices” because of the barriers to communication. At research centers, senior engineers typically have individual offices or cubicles, and colleagues are spread over multi- ple buildings at the local campus. Projects can also involve collaboration with an off-site coworker, such as a university professor. For (a) (b) our experiment, we refactored our office cubi- cal layout into a commons and alcoves5 devel- Figure 1. (a) The original 15´× 17´ office layout: large, isolated opment room (see Figure 1), with copious work spaces with desks separated by towering bookcases and marker board space and a pair programming joined by a narrow aisle. (b) The refactored layout: small, station. The pair programming station had si- isolated work spaces with tables and a large common area multaneous dual keyboard and mouse inputs consisting of a Beowulf cluster, a pair programming station, a connected to a 16-processor Beowulf cluster conference table, and whiteboards. We can move the partition (see Figure 2). at the upper right to further isolate a private work area, and Implementing XP practices all three areas can now accommodate pair programming. We made a serious effort to apply the 12 XP practices by the book (see Table 1 for a sum- mary of our experience). Due to the six cultural conflicts just listed, eight of the 12 XP practices presented implementation challenges. On-site customer The biggest challenge was the on-site customer. XP places a premium on the customer–developer relationship, requiring an on- site customer. Both the customer and developer have clearly defined roles with distinct respon- sibilities, interacting on a daily basis. The customer focuses the developer on the business value, while the developer educates the customer on the feasibility and cost of feature re- quests. In the context of long-term research, the technologies being explored might be immature or uncertain, years removed from commercial potential. In this situation, the funder is too far Figure 2. The pair programming station has two task chairs, removed from the research to serve as a suitable a 60-inch-wide Anthro AdjustaCart, wireless keyboards and customer. So, the researcher is essentially the × mice, and two LCD displays supporting a merged 2560 1024- “customer” for his or her own development ef- pixel desktop. You can see the sustenance items—refrigerator, fort—at least for several years. What happens microwave, fresh-air supply, and plants—on the right.

Load more