Exceptional experimentation with extreme programming
Bill Weaver, Ph.D.
We have recently upgraded our laboratories with some modern analytical instrumentation. Each of these devices consists of very impressive technology permitting rapid analysis of samples at a level of convenience and automation that was the stuff of science fiction only a few years ago. However, the most common shortcoming of each instrument is its associated software application. I know it is common to absolutely hate the latest video game until you learn how to play it, but after working with these instruments it is easy to wonder if the software engineers have ever seen the instrument attached to their application, let alone have had to use it several hours per day. No matter how innovative the instrument, the user can’t help but base their opinion of the entire instrument on the application interface they must use to operate it.
Attaching an instrument to a control computer can be a very straightforward process. The number of channels to be monitored along with each channel’s frequency, dynamic range, slew rate, and required resolution are compared against a matrix of available data acquisition and control devices such that the appropriate hardware can be specified. Unfortunately, simply handing these specifications over to the software development team does not insure that they will create something that a user would want to drive. There is a high level of artistry involved in not only displaying the required information in a convenient format, but also facilitating parameter adjustments in an intuitive manner. In a university setting, instruments are typically operated by a continuous stream of new students and visiting researchers. Control program idiosyncrasies such as common instrument parameters buried a few menus deep become evident very quickly.
Traditional software development includes the creation of a lengthy specification document based on user requirements that predicts how customers will use the instrument. Programmers design the application according to the specification and then release a nearly complete “beta” version to the customers for minor tweaking and bug detection. After delivery of the release version, a “post-mortem” is performed on the project with the aim of improving the entire process for the next application. This development method is not designed to accommodate change.
Rather than attempting to capture and predict future customer needs in the initial specification, “agile” software development methods are optimized to adapt quickly to changing customer desires. This does not mean the software chases after fickle customer whims. It acknowledges the reality that the customer may not have a concrete picture of how the new instrument will be incorporated into the laboratory. One such method includes end users or customers as members of the software development team. Known as Extreme Programming (XP), this agile software development process stresses adaptation to evolving system requirements through the delivery of thoroughly tested incremental releases rather than the production of a single end version generated in response to a detailed and complete specification. The initial specification is replaced by short “user stories” that are written by the customer to describe how they would ideally prefer the to use the instrument. The programming team scripts these stories in short iterations lasting one to three weeks and delivers a tested, bug-free working program back to the customer team. The customer team creates additional stories describing enhanced functionality for the next programming iteration. This processes permits the users to gain a look and feel of the program during its early development. Things that are heading in the wrong direction can be caught and changed before the entire application is wrapped around a bad fundamental design. More importantly, by using a few-featured version of the program in the laboratory, users can gage the instrument’s impact on productivity and rank the importance of accessories required in the final full-featured version.
XP and other agile development methods are receiving much attention in the computer sciences for being new and controversial, however, the experimental diagnostic community has been using these practices successfully for decades. When setting out to create a computer-based data acquisition system for a new experiment, it is impossible to create an initial software requirements document. Software development is immediately preceded by additional experiments and the software is designed to accommodate recent findings. Incorrect hypotheses often require the software to be redesigned or scrapped entirely. As new instruments continue to be delivered with accessories for changing their experimental configuration, we should expect the operating software to be customizable as well.
Bill Weaver is an assistant professor in the Integrated Science, Business and Technology Program at LaSalle University. He may be contacted at firstname.lastname@example.org.