Two weeks ago, Austin Vance at Pivotal Labs loaned me a copy of Kent Beck’s and Cynthia Andres’s book Extreme Programming Explained. For those unfamiliar, a one-line description:
Extreme Programming, or XP, encompasses a set of values, principles, and practices for software engineering teams to increase productivity, decrease waste, and improve predictability on their software projects.
Thirsty for more? Here’s a more comprehensive rundown, or you could purchase the book itself.
If you’re looking for the Cliffs Notes, this is definitely not your blog post. Rather, it’s a short selection of salient points from the book—namely, points that piqued my interest enough such that I would like to learn more about them than what is contained inside it.
Onward!
1. Pairing
One of XP’s flagship practices prescribes that programmers work together in twosomes. The twosomes help keep programmers honest to the other practices (like TDD), allow for on-the-fly problem-solving brainstorm sessions, and reduce errors in code as one programmer reviews the other one’s typing. The book describes what pairing is and what it’s good for. It also dips its toe into how to do it—mind your partner’s personal space, don’t wear strong cologne, et cetera.
So we got the grand overview and the most granular nuts-and-bolts. I, for one, would be fascinated to read more about the interpersonal aspects of pairing effectively.
I wonder, for example, when and how should I take over when my pair is frustrated? When should I just let them think, and when do I step in and help?. If this is too specific to individuals, then we can take a step back and ask how we get good at these things, even when pairing with different individuals. This is the type of soft skill that many programmers lack AND fail to pursue, hence the reputation for engineers being awkward, introverted, and not sociable.
I have never paired with Kent Beck and therefore cannot speculate on what that experience is like, but I would be interested to know how he does it. If this type of thing is not an issue to which he has paid attention, I would be interested to see Cynthia Andres express her thoughts and experiences related to the social side of improving the pair programming experience, on a more intangible level than “don’t wear terrible cologne” and “respect your partner’s personal space,” which is the extent of the detail on this topic into which the book delves at present.
2. Test-Driven Development
This is another flagship XP practice: write a test that fails, make it pass, refactor your code.
We’ve all stared at a console and wondered why the heck our program did…well, what it did, rather than what we meant for it to do. In dealing with defects such as these, we can find tomes of information about how to debug it, where to look for problems, and what might fix these issues. Extreme Programming Explained takes a look at this same question, but identifies TDD, not just as an aid, but as an essential component of the un-defecting process: how do we solve a confounding and persistent bug with the aid of tests?
Kent prescribes an elegant and inspiring solution:
- Develop a system-level test for the desired behavior. Ensure that it fails.
- Write an eensy-teensy test for the tiniest scope of the program that you think might be the problem. Make it pass.
- If tiny test passes and system test fails, you’ve eliminated a suspect on the list of problems. Make another tiny failing test of slightly wider scope.
- Repeat until the system passes.
What I would love to have seen: a concrete example of this. I don’t want to speak too soon because another of Kent’s books, Test-Driven Development by Example, might provide exactly what I’m looking for (I’ll let you know in a week). That said, I still think there is a place for a concrete example even in a book that extracts the “essence” of XP to its most abstracted form. In fact, in discussing how the example might change, even hypothetically, to model different problems can sweep out an abstract solution with the programmer’s version of an illustration. I would bookmark such a section to read over and over again.
3. Adopting XP
The book contains several sections discussing how to adopt XP in the workplace. On the speed at which to change the system, though, the book offers only this piece of advice: don’t go to fast, but know that you can often go faster than you realize. Not very concrete.
I understand that different speeds will be right for different teams. My question to Kent here goes like this: are there signals that we can use to determine if we are adopting XP too quickly on a software team? Too slowly? How do we differentiate these signals from symptoms of other problems on the team? How do we address those challenges in a way that keeps morale high?
Given the social dynamic of the above questions, this might be another opportunity for Cynthia to lend her expertise.