See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/3249531

Development of a Weather Forecasting Code: A Case Study

Article  in  IEEE Software · August 2008

DOI: 10.1109/MS.2008.86 · Source: IEEE Xplore

CITATIONS READS
29 734

8 authors, including:

Richard P. Kendall Jeff Carver

United States Department of Defense University of Alabama
59 PUBLICATIONS   922 CITATIONS    133 PUBLICATIONS   3,868 CITATIONS   

SEE PROFILE SEE PROFILE

David Fisher Douglass E. Post

Institute of Electrical and Electronics Engineers Carnegie Mellon University
46 PUBLICATIONS   1,266 CITATIONS    259 PUBLICATIONS   5,863 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Cyber-security View project

Emergent Algorithms View project

All content following this page was uploaded by Susan Squires on 05 August 2013.

The user has requested enhancement of the downloaded file.

focus
developing scientific software

Development of a
Weather Forecasting Code:
A Case Study
Richard Kendall, David Fisher, and Dale Henderson, Software Engineering Institute

Jeffrey C. Carver, Mississippi State University

Andrew Mark, Douglass Post, and Clifford E. Rhoades Jr., US Department of Defense
High Performance Computing Modernization Program

Susan Squires, Sun Microsystems

C
omputational science is increasingly providing insight into scientific phenom-
A case study of a
ena that have previously been studied only experimentally, observationally, or
weather-forecasting
theoretically. Codes, the software projects written for computational science,
code aimed to generally have three main differences from traditional software projects, such
investigate the as those from the commercial software domain. First, because these projects often per-
code development form new scientific investigations, the requirements can’t be known in advance and must
challenges, evolve over time. Second, the main driving force for these projects is producing correct,
understand the important scientific advances rather than ensuring ■ identifying issues that hardware and software
development tools software quality through formalized software engi- vendors must address to make the code devel-
neering processes. Finally, these projects’ developers opment process more productive,
used, and document tend to be domain scientists rather than software ■ developing a reference body of case studies for
the findings for engineers, so they’re less likely to use any heavy the computational science and engineering com-
other developers. software development processes.1–3 munity, and
To better understand the impact these character- ■ documenting the lessons learned from analysis
istics have on software development practices in the and personal team interviews.
computational-science domain and to document
lessons learned for similar projects’ benefit, we per- For this case study, we followed the same meth-
formed a series of case studies of computational- odology that we used in the previous case stud-
science code development projects sponsored by the ies.2 Here, we provide only a basic overview of the
Darpa High Productivity Computing Systems pro- methodology to give context for understanding the
gram. Here, we describe the sixth case study (after results. After we identified a suitable project, the
Falcon,4 Hawk,5 Condor,6 Eagle,7 and Nene8). team completed a questionnaire. We used the re-
The common objectives for all case studies were sponses to plan an on-site interview, after which
we iterated the results with the code team to ensure
■ identifying critical success factors, correctness.

0 74 0 -74 5 9 / 0 8 / $ 2 5 . 0 0 © 2 0 0 8 I E E E July/August 2008 I E E E S o f t w a r e  59

 Code characteristics Furthermore, using an all-Fortran code eliminates
Osprey is one component of a large weather- complicated make and link operations and other
At the forecasting suite that combines the interactions of problems associated with using multiple program-

highest level, large-scale atmospheric models with large-scale

oceanographic models. Osprey’s current code—
ming languages. The project leader hasn’t en-
countered any limitations in Fortran (augmented
the Osprey which has evolved from other codes that date with the MPI) that would cause him to seriously
code team back to 1974—has been used operationally for 10
years. Development of the present version began
reconsider the choice. Moreover, programming-
language evaluation has been a distraction in the
has some in 1988 as a research project that aimed to extend past, so the team is reluctant to invest resources
control over the the predecessor code’s capabilities. At the highest in this area unless it has identified a specific need,
level, the Osprey code team has some control over such as the one that led to implementing MPI.
requirements the requirements through the proposal process. Essentially one version of the Osprey program
through the That is, the team can make direct proposals to po- library executes on SGI, IBM, HP, and Linux plat-
proposal tential sponsors about features to implement in the
code. This process is how the team acquired fund-
forms. A locally built preprocessor configures the
code for each supported platform. Compiler flags
process. ing for code-directed goals such as the implemen- configure the code to run using different par-
tation of the Message Passing Interface (MPI) and allel-programming libraries (such as MPI and
nested grids. The sponsors, which have increased OpenMP).
in number in recent years, often set the require- Parallelization is a key priority because the team
ments through directed research and development must use parallel computation and processing to
grants (that is, unsolicited grants). Work tends to achieve the performance level needed to obtain the
be funded in ever-smaller increments (relative to expected scientific results. Conversely, actual dem-
constant costs), and individual code developers onstrations of parallel performance haven’t reached
now work in multiple topic areas rather than spe- the level that the Osprey development team be-
cializing in one topic. lieves is feasible. This shortfall results from the fact
Osprey is distributed via the Web. It has no li- that, to maintain portability, the code isn’t highly
cense fee, and the team has deployed a home-grown tuned for any specific parallel platform; however,
license manager to track the code’s distribution. some optimization occurs for each platform. In
Osprey has been downloaded hundreds of times by general, however, the team avoids the use of li-
institutions worldwide. Some institutions have hun- braries and machine-dependent features. Earlier
dreds of users. attempts at hardware-based customization led to
Because the Osprey code is one component in a cluttered, unmanageable code. The emphasis now
larger system of systems, its architecture lets it both is on general, flexible, and scalable code.
send and receive information from the other system
components. A framework supports one-way and Code project and team
two-way coupling of Osprey to other system com- Osprey’s core team consists of about 10 develop-
ponents, using an exchange grid to facilitate data ers and a few outside consultants and postdoctoral
exchanges between components. researchers. The core team is located at a single
With the exception of approximately 300 lines site along with most of the development teams for
of C code, Osprey is written in a Fortran subset the other components in the larger system of sys-
(which we describe in the next section). There are tems. However, other sites also contribute com-
approximately 150 KLOC in Fortran, of which ponents. Most of the core team members have
approximately 50 KLOC are comments. The driv- worked together for the past 10 years. The team
ing motivation behind choosing Fortran was the leaders have preferred to recruit staff members
need for portability and ease of development and who already have domain knowledge. Moreover,
maintenance (similar to our findings in the Falcon, the team has generally found individuals with
Condor, and Nene case studies). After consider- computer science backgrounds to be helpful for
ing these needs, Osprey determined that Fortran specific coding tasks or applications, but it hasn’t
was the best language available when development utilized computer scientists as part of the primary
began. Although university computer science de- code development team. The team has had diffi-
partments no longer routinely teach Fortran, new culties interfacing with pure computer scientists
developers can master its fundamentals in a week that have had little exposure to large weather or
(using Fortran 77) to a few months (Fortran 90). oceanography codes. As an example of the dif-
In contrast, C++ or other modern, higher-level ficulties the team has experienced working with
languages typically take much longer to master. computer scientists, the Osprey team leader cited

60 IEEE Soft ware w w w. c o m p u t e r. o rg /s o f t w a re

a computer scientist who wanted to make every velopment processes, it follows an agile philosophi-
executable line of the code into a subroutine to cal approach (www.agilealliance.com) in the sense
make the code easier to debug. that it emphasizes practices over process. Table 1
The Osprey team describes itself as follows: summarizes the extent to which the Osprey team
uses various development practices.
■ Team members have a common professional Of the 20 or so software development tracking
background. metrics9 cited in the software engineering literature,
■ Team management processes are largely infor- the Osprey team employed
mal and collegial.
■ There is strong peer pressure to contribute and ■ lines of code,
strong team member dedication to the project. ■ code performance,
■ The team views code validation as especially ■ degree of performance optimization,
important. ■ parallel scaling,
■ number of users, and
The Osprey team indicated that code main­ ■ computer time used for code development.
tenance, portability, and speed-to-solution are the
main drivers of development, with ease of main- LOC is a general measure of the code’s growth.
tenance being paramount. They also emphasized There is growing pressure from sponsors for sci-
flexibility, by which they mean ence metrics, not code development metrics.
Osprey’s approach to configuration manage-
■ the code must run on many platforms, ment is similar to that of the other projects we’ve
■ the code must port easily to the next generation studied. A part-time source code librarian uses
of hardware, and Subversion (http://subversion.tigris.org) to manage
■ the code can’t be tailored to any particular the code. The code librarian logs the bugs. No for-
platform. mal issue-tracking system has been deployed, nor
does one appear to be necessary. The code librar-
This definition of flexibility represents a conscious ian requires a prologue detailing a subroutine’s
attempt to manage an important technological risk. purpose before it can be committed to the code li-
The Osprey developers aren’t encouraged to use all brary. Verification tests are also required.
of the constructs that Fortran supports. The prac-
tice within the Osprey development community is Code life cycle
to use only features that are well tested and reliable. and workflow management
The team follows a style guide and uses the struc- Much of the Osprey program library’s code is in
ture and coding practices of the code itself to train maintenance. Because Osprey is undergoing con-
new team members. tinuous enhancement, there’s always new develop-
Osprey and the developers of the other system- ment and testing. At any given time, code modules
of-systems components are colocated and under a in the program library range from brand new to
common management structure. This colocation, 20 years old. This project’s workflow is typical of
along with the Osprey development team’s rela- the other projects that we’ve studied, consisting of
tively small size, has limited the degree of formal- the following steps:
ity needed to manage the team. The Osprey team
doesn’t adhere to any formal code development ■ question formulation,
methodology (such as CMM, ISO, or even for- ■ development approach formulation,
mal agile development processes). However, the ■ code development,
team has adopted repeatable coding practices and ■ testing (validation and verification),
employs coding-style requirements and standards. ■ production,
From the formal software engineering viewpoint, ■ analysis, and
this project is underconstrained—as have been all ■ hypothesis formulation.
but one of the other computational science projects
that our team has examined in case studies. This (This isn’t customary software engineering
approach is successful because, for the most part, language—such as requirements gathering or
the Osprey team can set its own milestones with specifications formulation—but it’s more de-
the sponsors’ approval; thus, the iron triangle (that scriptive of the actual workflow management
is, the scope, resources, and schedule) isn’t violated. process the computational-science projects we
Although the team doesn’t identify with formal de- studied employed.)

July/August 2008 I E E E S o f t w a r e  61
 Table 1
The Osprey team’s development practices
Practice Description Followed Comments
Collective Allow anyone to change any code anywhere in the Partially Followed to a small degree; a limited set
ownership system at any time. of developers allowed to make changes

Configuration Establish and maintain the integrity of work products Yes A key role in this project
management using configuration identification and control.

Continuous Integrate and build the system many times a day, Partially Performed weekly rather than daily
integration each time a task is completed.

Feature-driven Establish an overall architecture and feature list, Yes Project development driven by new features
development then design by feature and build by feature.

Frequent delivery/ Have many releases with short time spans; No Driven by task—no explicit goal to have
small releases implement the highest-priority functions first. small releases, although this often occurs

Onsite customer Include a real, live user on the team who is available Yes Code’s developers are also users
full time to answer questions.

Organizational Follow an organization-wide process. No No formal organization-wide process

process definition

Organizational Develop team members’ skills and knowledge so No Nothing formal in place
training that they can perform their roles effectively.

Pair programming Work side by side with another programmer at one No Not found to be useful
computer, collaborating on the design, algorithm,
and code.

Planning game Quickly determine the scope of the next release No Not used
with business priorities and technical estimates.

Peer reviews Review peers’ software artifacts (requirements, Partially Informal code reviews (but not
design, code) to improve quality. requirements or designs) used

Process and product Objectively evaluate adherence to process Partially Long-term roadmap for Osprey, but
quality assurance descriptions and resolve noncompliance. no formal monitoring of adherence
to the development strategy

Project monitoring Provide an understanding of the project’s Yes Internal and external reviews throughout
and control progress so that appropriate corrective actions the year; local groups meeting weekly
can be taken if progress deviates from plan. to discuss issues

Project planning Establish and maintain plans that define project Yes Planning done at the beginning of each
activities. fiscal year as part of the funding cycle

Refactoring Restructure software to remove duplication, Yes Used to improve performance and make it
improve communication, simplify, or add flexibility. easier to change the code in the future

Requirements Produce, analyze, and verify customer, project, Yes A formal process followed as part of
development and product requirements. proposal generation

Requirements Manage the project’s requirements and identify Yes Internal milestones set by each subteam
management inconsistencies with the project plan.

Retrospective Perform a postiteration review of the effectiveness Yes Performed at the annual review
of the work performed, methods used, and estimates.

Risk management Identify potential problems and adequately handle Partially Emphasis on testing and benchmarking;
them. conscious strategy for managing technology
risks; no formal management of other risks

Simple design Design only what is being developed, with little Partially There’s a long-term plan beyond the current
planning for the future. funding; the design is documented only in the
code, so features that aren’t coded haven’t been
formally designed
Tacit knowledge Maintain and update project knowledge in Yes Tacit knowledge in the scientific discipline
participants’ heads rather than in documents. is important

Test-driven Write module or method tests before and during Partially Testing integrated with development
development coding.

62 IEEE Soft ware w w w. c o m p u t e r. o rg /s o f t w a re

 The development path through these steps is
Code development environment
iterative. The team developed physics prototypes
Compilers Fortran, C
for testing in the Osprey code framework. The Scripts Perl
team wrote these prototypes as candidates for di- Debuggers DX, TotalView
rect inclusion into the code, so there’s also an as- Performance analysis: profilers prof
pect of spiral development. Unlike some other proj-
ects we’ve studied, these prototypes aren’t written Execution environment
Element/grid generation GrADS
in a higher-level language such as Matlab. How-
Visualization IDL, Matlab
ever, the Osprey team sometimes uses Matlab to Data analysis IDL, NCAR command language
study parameterization issues. There is some refac-
toring of old modules as capabilities are replaced Code development process tools
or enhanced. The project has no mandated release Configuration management Subversion
schedule; releases occur when new capabilities or Bug tracking No formal tools deployed
Code documentation Users’ manual, code documentation, Web site
bug fixes are ready. Last year there were 10 re-
leases, but some were small fixes. The download- Support libraries
able version is two years old (that is, well behind Computational mathematics BLAS
the most current version). Parallel-programming libraries MPI, MPI-2, OpenMP
As we’ve observed in our other case studies,
most sponsors don’t directly fund code mainte- Figure 1. Osprey’s
nance. It’s not entirely clear that development is of our previous studies’ findings. life-cycle management
funded directly either—the funding is usually di- First, the Osprey team members articulated the tools.
rected toward the science, not the code. following lessons learned:
The team does testing both during and at the
end of development. Team members can’t submit ■ If it’s important, do it right.
new capabilities for inclusion in the Osprey pro- ■ Listen to the customer.
gram library unless the capabilities pass verifica- ■ Data assimilation becomes increasingly impor-
tion tests. The developers do substantial testing tant as the model grows in sophistication.
before submitting capabilities to the configuration- ■ Configuration management is essential.
management process. Team members share quality ■ Physical parameterizations remain a necessary
assurance. After internal testing, the code is trans- evil, but you should avoid them if physical mod-
ferred to a primary customer for additional, inde- els are feasible.
pendent testing prior to release. For major changes, ■ Validation and verification are crucial to im-
an independent panel with broad stakeholder rep- proving and accepting scientific codes.
resentation performs a series of tests before the ■ Strive for performance, but not at all costs.
transition to production. ■ Build flexibility into the system.
A goal of our case studies has been to document
the tools the code development teams use (see Fig- In our previous case studies of computational
ure 1 for a summary of these for Osprey). The use science codes, we made nine observations about the
of particular tools, such as TotalView, hasn’t been software development environments used.2 The les-
mandated and is often a matter of personal prefer- sons the Osprey team learned and our observations
ence. IDL is used primarily by customers, not de- from the questionnaire and interviews provided
velopers. In general, developers prefer open source support for seven of those earlier observations.
tools. Here, we describe them in more detail along with
the supporting information from the case study.
Lessons learned
All our case studies have extracted important les- A code project’s primary language is
sons for the computational science and engineer- constant over the project’s long lifetime
ing code development community. These lessons These projects tend to last multiple years (even de-
can guide software engineers seeking to better un- cades), as evidenced by the fact that some of the
derstand how to successfully work with this type Osprey project’s code dates back 30 years. There-
of code project. In this case study, we present two fore, you might expect that the programming lan-
types of lessons learned. First, we describe the les- guage would evolve over time as more modern
sons the Osprey team members learned. Then we languages are developed and standardized. Con-
combine those lessons with our observations from versely, in Osprey and the other codes we studied,
the questionnaire and interviews into the context the basic language didn’t change over time. The

July/August 2008 I E E E S o f t w a r e  63
 Osprey team still uses Fortran because it’s easy development teams can function well with a very
to learn compared with modern languages. This lightweight process as long as teams are small, per-
The Osprey is true also because the team has yet to encounter form adequate planning, and have good commu-

team still a weather-modeling requirement that couldn’t be

programmed efficiently, both in terms of program-
nication among team members. Although Osprey
and the other code teams we studied didn’t use one
uses Fortran mer effort and execution time, using Fortran. of the formal agile methodologies (such as Scrum
because it’s Use of higher-level languages is low
or XP), they did operate their team according to the
mind-set proposed in the Agile Manifesto (http://
easy to learn The Osprey project uses high-level languages such agilemanifesto.org). The choice to operate this way
compared as Matlab very sparingly, if at all. In some other emerged out of necessity rather than a conscious
cases, we’ve seen Matlab used as a prototyping lan- decision to follow one specific agile approach over
with modern guage almost akin to a statement of requirements. another.
languages. But none of the projects we studied extensively used
such languages. Multidisciplinary teams are important
The complex nature of the scientific domains for
Risk management is important which computational science is effective necessitate
These types of projects’ long lives present risks that that much of the code be written by domain ex-
aren’t always present in other types of software. In perts (scientists). It’s simply too difficult to teach a
our previous studies, teams viewed externally devel- computer scientist or software engineer the techni-
oped tools and libraries as risky because of the like- cal details of a scientific domain for which a PhD is
lihood of the vendor going out of business during needed to even understand the problem to be solved.
the project’s life cycle. For the Osprey project, lack In many cases, including Osprey, these teams have
of flexibility was an important risk. To address this found it effective to use computer scientists’ exper-
risk, they designed and implemented the code so tise and ability to perform specific coding tasks that
that it wasn’t closely tied to any particular platform don’t require extensive domain knowledge.
and could be easily ported to new platforms as they
became available. Project success or failure depends on
keeping customers and sponsors happy
Performance isn’t the only As in any type of project, its longevity depends on
important nonfunctional requirement its success among its customers. One unique aspect
All the code projects we studied used high- of the computational science projects we studied,
performance supercomputers, so performance (that including Osprey, is that the customer and the users
is, speed of execution) was an implied goal. In Os- aren’t always the same group of people. So, to be
prey, performance is an important goal, but only to successful, a project must keep both the users (other
the extent that it improves the code’s scientific out- scientists) and the customers (the sponsors or fund-
put. In other words, scientific goals drive the need ing agencies) satisfied. If the code project meets the
to achieve a particular performance level. Osprey’s technical goals the customers set, but isn’t seen as
main focus is to support scientific research, not useful by the end users, then it won’t be viewed as a
to demonstrate computer science ability or even success over the long term.
achieve impressive performance numbers. Although

W
it isn’t the main driver, code performance is still im-
portant to the Osprey team because its customers e hope that these lessons learned will
require real-time applications that support opera- be useful to other scientific-code devel-
tional functions. In addition, as discussed earlier, opers. We realize that the Osprey proj-
maintainability and portability are also essential to ect might be unique and might not represent expe-
the Osprey code’s success. riences in other domains. Nonetheless, we believe
that many of these lessons are applicable to a broad
Agile approaches are better suited range of computational science projects.
than more traditional methodologies
In the projects we studied, including Osprey,
Acknowledgments
scientific-code teams valued agility over formalized We thank the Osprey team members for participating
processes. That is, they usually avoided rigid soft- in this case study. Air Force grant FA8750-05-1-0100
ware management approaches, but planning and supported this research in part.
Osprey is a pseudonym; we have masked or omit-
adoption of useful software practices are important ted any details that might reveal the code project’s
to the success of these projects. We’ve found that identity.

64 IEEE Soft ware w w w. c o m p u t e r. o rg /s o f t w a re

References 6. R.P. Kendall et al., Case Study of the Condor Code
1. J.C. Carver, “Post-Workshop Report for the Third In­ Project, tech. report LA-UR-05-9291, Los Alamos Nat’l
ternational Workshop on Software Engineering for High Lab, 2005.
Performance Computing Applications (S ehpc 07),” ACM 7. R.P. Kendall et al., Case Study of the Eagle Code Proj-
S igsoft Software Eng. Notes, vol. 32, no. 5, 2007, pp. ect, tech. report LA-UR-06-1092, Los Alamos Nat’l
38–43. Lab, 2006.
2. J.C. Carver et al., “Software Development Environ- 8. R.P. Kendall, D. Post, and A. Mark, Case Study of the
ments for Scientific and Engineering Software: A Series NENE Code Project, tech. note CMUI/SEI-2006-TN-
of Case Studies,” Proc. 29th Int’l Conf. Software Eng., 044, Software Eng. Inst., Jan. 2007.
IEEE CS Press, 2007, pp. 550–559. 9. E.E. Mills, Software Metrics, Software Eng. Inst. Cur-
3. L. Hochstein and V.R. Basili, “The ASC-Alliance Proj­- riculum Module, SEI-CM-12-1.1, 1988, www.sei.cmu.
ects: A Case Study of Large-Scale Parallel Scientific edu/pub/education/cm12.pdf.
Code Development,” Computer, vol. 41, no. 3, 2008,
pp. 50–58.
4. D.E. Post, R.P. Kendall, and E. Whitney, “Case Study
of the Falcon Project,” Proc. 2nd Int’l Workshop Soft-
ware Eng. for High Performance Computing Systems
Applications, ACM Press, 2005, pp. 22–26.
5. R.P. Kendall et al., Case Study of the Hawk Code Proj­-
ect, tech. report LA-UR-05-9011, Los Alamos Nat’l For more information on this or any other computing topic, please visit our
Lab, 2005. Digital Library at www.computer.org/csdl.

About the Authors

Richard Kendall is a visiting scientist at the Software Engi- Andrew Mark is the program manager for DoD software
neering Institute and retired CIO of Los Alamos National Laboratory. applications in the DoD High Performance Computing Modernization
His research interests include computational methods in partial dif- Program. His academic interests include continuum mechanics, and
ferential equations, computational physics of oil and gas exploration, his professional interests include the development of integrated
computer security, software engineering, and software assurance software tool suites for design, testing, and analysis of DoD materiel
processes. Kendall received his PhD in mathematics from Rice Uni- acquisition programs. Mark received his PhD in applied mechanics
versity. He’s a member of the Society of Petroleum Engineers and the from Drexel University. He’s a member of the American Institute of
IEEE. Contact him at [email protected]. Aeronautics and Astronautics and American Society of Mechanical
Engineers. Contact him at [email protected].

Jeffrey C. Carver is an assistant professor in the Computer Sci- Douglass Post is the chief scientist of the DoD High Perfor­
ence and Engineering Department at Mississippi State University. Be- mance Computing Modernization Program. He is a permanent
ginning 16 August, he’ll be an assistant professor in the Department of member of the senior technical staff of the Software Engineering
Computer Science at the University of Alabama. His re­search inter- Institute. At the HPCMP, he also manages the DoD Create program to
ests include empirical software engineering, software engineering for develop large-scale computational engineering tools for designing
computational science, software architecture, and requirements engi- ships, airplanes, and RF antennas. His research interests include the
neering. Carver received his PhD from the University of Maryland. development of computational engineering and science tools and
He’s a member of the IEEE Computer Society, ACM, American Society the associated software engineering issues. Post received his PhD in
for Engineering Education, and International Software Engineering physics from Stanford University. He’s a fellow of the IEEE, American
Research Network. Contact him at [email protected] until 16 Aug., and at [email protected]. Physical Society, and American Nuclear Society. Contact him at [email protected].
edu after that date.

David Fisher is the chief engineer for the Create program Clifford E. Rhoades Jr. is the technical director of the Maui
and project manager for Create infrastructure in the Department High Performance Computing Center under an Intergovernmental
of Defense High Performance Computing Modernization Program. Personnel Act assignment from the Software Engineering Institute. His
He completed the work described in this article while he was at the research interests include computational physics, high-performance
Software Engineering Institute. His interests include computational computing algorithms, and software engineering. Rhoades received
science and engineering, high-performance computing, software his PhD in physics from Princeton University. He was one of the first
engineering of complex systems, emergent behavior, and software five American Physical Society fellows elected in computational phys-
development infrastructure. Fisher received his PhD in computer ics. He’s a member of the ACM, the Air Force Association, the Ameri-
science from Carnegie Mellon University. Contact him at david. can Institute of Aeronautics and Astronautics, the American Physical
[email protected]. Society, the IEEE, and the IEEE Computer Society. Contact him at [email protected].

Dale Henderson is retired from the Los Alamos National Susan Squires is executive director of user research at Tac-
Laboratory after a long career in basic and applied research, with tics, a user and customer research consultancy firm that specializes
some focus on large-scale computation and computer simulation. in ethnography to gain insight in connecting what people do to what
Henderson received his PhD from Cornell University in applied phys- they say. She completed the work described in this article while she
ics. He’s a member of the American Physical Society. Contact him at was at Sun. She’s a practicing anthropologist with experience in
[email protected]. customer research, strategic planning, and program management.
Squires received her PhD in anthropology from Boston University.
She is a fellow of the Society for Applied Anthropology. Contact her
at [email protected].

July/August 2008 I E E E S o f t w a r e  65

View publication stats