NOVEMBER/DECEMBER 2004 (Vol. 21, No. 6) pp. 100-101
0740-7459/04/$31.00 © 2004 IEEE
Published by the IEEE Computer Society
Published by the IEEE Computer Society
|Introducing Test-driven Software Development|
|Gently Making the Case for Pair Programming|
PDFs Require Adobe Acrobat
Introducing Test-driven Software Development
Test-Driven Development: By Example by Kent Beck, Addison-Wesley, 2003, ISBN 0-321-14653-0, 220 pp., US$29.99.
There are really two things to review here: the book and its topic. The topic is test-driven development (TDD), the latest brain-child of Extreme Programming inventor Kent Beck. The idea is simple: rather than writing code first and testing it later (maybe never), write unit tests first and only add code to make the unit tests succeed. This method guarantees the existence of a complete, up-to-date suite of unit tests, which serve as the ultimate spec of the eventually delivered software system. More importantly, it frees software developers from the all-too-familiar nightmare of their latest innocuous change breaking the entire application: the unit tests act as an ever-present safety harness. In the same way that a safety harness liberates a mountain climber to creatively ascend to the summit, the suite of unit tests enables software developers to refactor much more aggressively. And in fact, refactoring is the last and necessary step in the TDD cycle.
Of course, this idea runs counter to most organizations' common practice and perhaps to our intuition as well. But its appeal is compelling and undebatable. Implementing this idea comes with some challenges, not the least of which is that it requires sophisticated tool support to become feasible. Also, I seem to recall some real-life applications that didn't break down into independently testable units as easily as Beck's examples—although better design might have fixed that. In any case, TDD is here to stay, and software professionals should become familiar with it.
Which brings us to the book. It's short, and Beck apparently wrote it in a hurry (in the acknowledgments, he seems to suggest that he finished it within two months, a claim that seems quite plausible to me). The first two sections—over half the book—cover two explicitly worked example applications, developed following the TDD method: one in Java and one using Python. These examples read like transcripts of in-class tutorials, both in the level of detail (he walks the reader through every step of the design, testing, and coding process) and in their chatty, colloquial style ("If you're upset, take a cleansing breath. In through your nose ... hold it 1, 2, 3 ... ," and so forth). Unfortunately, this kind of patter, engaging as it is in a lecture hall, easily becomes quite tedious on the printed page.
The book's third part comprises several chapters with recommendations on various aspects of the TDD process, given in an abbreviated "pattern" format. I'd prefer a more elaborate and better organized presentation here—some of the discussion is rather sketchy. The pattern format's focus on independent discussions of separate concepts doesn't make for easy reading. Often, Beck names a pattern before he introduces it, without explicit forward references. This isn't a big deal, but it's unnecessarily confusing and no service to the reader.
Unfortunately, several such minor omissions and underdeveloped areas mar the book's usefulness. Particularly surprising is the absence of a thorough description of unit testing tools, of which JUnit ( www.junit.org) for Java is the most well-known. The author uses JUnit extensively in the first case study without properly introducing it, leaving the reader befuddled as to what it means to "get a red bar."
Test-driven development is brand-new, and this is the first available book on the subject. It'd be unfair to expect a definitive treatise at this point. Beck has a great case to make, and he makes it well. Nevertheless, it's a little disappointing to read his book and think how much better it could've been.
Philipp K. Janert is a software project consultant and maintainer of the beyondCode.org Web site. Contact him at firstname.lastname@example.org.
Gently Making the Case for Pair Programming
Pair Programming Illuminated by Laurie Williams and Robert Kessler, Addison-Wesley, 2003, ISBN 0-201-74576-3, 288 pp., US$34.99.
One of the things that drew me to this book was Laurie Williams' work. She's been the voice of reason in an otherwise cacophonous chorus espousing everything agile and Extreme Programming. She's designed, led, and reported on numerous empirical pair-programming studies that have formed the basis of the substantial interest in it. In this volume, the authors discuss results such as higher quality by introducing fewer defects, higher quality by earlier defect detection, shortened duration (by half) compared to individual contributors working as they normally would, higher morale, higher trust of teammates, greater overall system knowledge, and enhanced learning.
What is pair programming? The book defines this as "two programmers work together at one computer on the same task" at the same time. It's one of the 12 practices of Extreme Programming.
This encyclopedic work distinguishes itself in several respects. Unlike nearly all other agile and Extreme Programming literature, this is not angry, not proselytizing, not exaggerating benefits, and not saying, "Trust me!" It also answered all my questions, even a few that I hadn't thought of! Instead of dictum, this volume cites empirical justification most often and case studies or individual experience least often.
The book's organizing principle clearly targets implementation. It addresses potential impediments, including how to assign and rotate team members, give appropriate credit to members with uneven contributions, cope with experience and personality differences, and sort out disagreements between a pair working together. Notably, the book features a case study that combines pair programming with the Personal Software Process and an appendix on pair-programming economics.
In the end, the authors find that while there's much to recommend pair programming, it also has numerous prerequisites that need attention and refreshing, so pair programming is not for every person or organization.
The style is airy, conversational, and not preachy. The work concentrates on understanding pair programming as deeply as possible from many viewpoints, including a programmer's, supervisor's, and manager's. It's oriented toward changing behavior because after all, pair programming is a behavior, not a method or process. Therefore, the book first tries to win our hearts and minds—by appealing to benefits and positive field experience—and then suggests how we can actually change the way we work at our desks in our organizations.
Stan Rifkin is a principal with Master Systems and is the associate editor in chief for quality at IEEE Software. Contact him at email@example.com.