Code Complete on Extreme Programming
October 10, 2003
Dave Hoover : Home

...the [XP] phenomenon looks almost like mass hypnosis.
Steve McConnell in The New X-Men by Martha Baer
I was in the middle of Steve McConnell's Code Complete when I read the above quote in Martha's article. Steve's apparent disdain toward XP surprised me because I saw so much in his book that supported XP. It seems to me that if one were to follow Code Complete to the letter, the resulting project would have some striking similarities with XP.

Below, I present the nine XP practices that are supported in Code Complete. I provide references from Code Complete (left column) and the supporting XP literature (right column). Numbers in parentheses indicate page numbers in Code Complete, otherwise numbers refer to page numbers in the book that precedes them.

Rather than latching on to the latest miracle fad, use a mixture of methods. Experiment with the exciting, recent methods, but bank on the old and dependable ones. (789)
It's interesting to note that XP could be described both as the latest miracle fad and as a mixture of old, dependable methods. Each of XP's twelve practices are based on practices that have been in the software industry for decades.
None of the practices described...is unique or original. They have all been used for as long as there have been programs to write. (Extreme Programming Explained, 63)

Test-Driven Development

...find an error as close as possible to the time at which it was introduced. (25)

  The sooner you find and fix a defect, the cheaper it is, often dramatically so. (Test-Driven Development, 202)

As you're writing the routine, think about how you can test it. (59)

  The best way to write tests for a class is to write them first... (Extreme Programming Installed, 94)

You can catch an amazing number of subtle errors simply by allowing the compiler to detect them. ... After stepping through the code in the debugger, test it using the test cases you planned while you were developing the routine. (69)

  Rather than apply minutes of suspect reasoning, we can just ask the computer by making the change and running the tests. (Test-Driven Development, 46)

The idea is to start with something concrete, worry about only one thing at a time, and build up...from simple components. Take small understandable steps as you make [the code] more general and complex. That way you minimize the amount of code you have to concentrate on at any one time and therefore minimize the chance of error. (344)

  Imagine programming as turning a crank to pull a bucket of water from a well. ... You need a rachet mechanism to enable you to rest between bouts of cranking. ... The tests in test-driven development are the teeth of the rachet. Once we get one test working, we know it is working, now and forever. ... Now we get the next one working, and the next, and the next. (Test-Driven Development, xi)

Plan the test cases...at the design stage or as early as possible -- preferably before you begin writing the unit to be tested. ... Build the test cases along with the product. (593)

  XP creates and maintains a comprehensive suite of tests, which are run and re-run after every change (several times a day), to ensure quality baseline. (Extreme Programming Explained, 4)

Ease of testing is another good reason to keep your routines short and your boolean expressions simple. (597)

  Keep methods small. If the code can't be seen in one display screen, it's too long. (Extreme Programming Installed, 80)

If you find it hard to create scaffolding for test cases because you can't call an individual routine easily, you should feel the "irritation of doubt" and ask whether the routine is coupled too tightly to other routines. (786)   The need to create test code that verifies each unit in isolation forces us to decouple the code in ways we might not otherwise think of. Thus, testability is a force that drives the design to a less coupled state. (Agile Software Development: Principles, Patterns, and Practices, 424)

Short Releases

In incremental development, you first make the simplest possible version of the system that will run. (14)

  ...the first iteration must be a functioning skeleton of the system as a whole... For the first iteration, pick a set of simple, basic stories that you expect will force you to create the whole architecture. (Extreme Programming Explained, 113)

If you want to build more flexibility into the requirements, you can set up an evolutionary delivery in which you plan to deliver the software in several stages rather than all at once. (777)   We want to know what kind of changes are likely before we are very far down the development path. ... We release the software early and often. We get it in front of our customers and users as quickly and as often as possible. (Agile Software Development: Principles, Patterns, and Practices, 105-106)

Continuous Integration

When new problems surface during incremental integration, the new routine is obviously at fault. (655)

  Integrating one set of changes at a time works well because it is obvious who should fix a test that fails... (Extreme Programming Explained, 60)

The liklihood that software will have serious problems during integration is directly proportional to the time between successive integration attempts. (668)   Integration is a bear. We can't put it off forever. Let's do it all the time instead. (Extreme Programming Installed, 78)

Refactoring

Move complicated expressions into boolean functions. (370)

  See Decompose Conditional. (Refactoring, 238)

Factor deeply nested code into its own routine. If deep nesting occurs inside a loop, you can often improve the situation by putting the inside of the loop into its own routine. (384)

  See Extract Method. (Refactoring, 110)

The smaller part of the job of programming is writing a program so that the computer can read it; the larger part is writing it so that other humans can read it. (406)

  Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (Refactoring, 15)

It's nearly impossible to produce a high-quality product unless you can systematically retest it after changes have been made. (618)

  Whenever I do refactoring, the first step is always the same. I need to build a solid set of tests for that section of code. (Refactoring, 7)

The key distinction between kinds of software evolution is whether the program's quality improves or degrades under modification. ... If you treat modifications as opportunities to tighten up the original design of the program, quality improves. (738)

  With refactoring you can take a bad design, chaos even, and rework it into well-designed code. Each step is simple, even simplistic. ... Yet the cumulative effect of these small changes can radically improve the design. (Refactoring, xvi)

Clean up the routine without changing its functionality. Then, with your increased understanding of the routine and the routine's increased readability, modifiability, and modularity, make your changes. (747)   Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. (Refactoring, xvi)

Metaphor

Important developments often arise out of analogies. By comparing a topic you understand poorly to something similar you understand better, you can come up with insights that result in a better understanding of the less-familiar topic. (7)

  We need to emphasize the goal of architecture, which is to give everyone a coherent story within which to work, a story that can easily be shared by the business and technical folks. By asking for a metaphor we are likely to get an architecture that is easy to communicate and elaborate. (Extreme Programming Explained, 57)

...the person who uses metaphors to illuminate the software-development process will be perceived as someone who has a better understanding of programming and produces better code faster than people who don't use them. (11)   ...each application should have a conceptual integrity based on a simple metaphor that everyone understands, explaining the essence of how the program works. ... Suddenly, a program that seemed mysterious and complex becomes clear and simple. (Extreme Programming Installed, 80-81)

Collective Ownership

Emphasize that code listings are public assets. Programmers sometimes feel that the code they've written is "their code," as if it were private property. Although it is the result of their work, code is part of the project and should be freely available to anyone else on the project who needs it. (529)   In XP, everybody takes responsibility for the whole of the system. Not everyone knows every part equally well, although everyone knows something about every part. If a pair is working and they see an opportunity to improve the code, they go ahead and improve it if it makes their life easier. (Extreme Programming Explained, 59)

Pair Programming

Assign two people to every part of the project. If two people have to work on each line of code, you'll guarantee that at least two people think it works and is readable. The mechanisms for teaming two people can range from team development to mentor-trainee pairs to buddy-system reviews. (528)   Two programmers working together generate more code, and better code, than the same two programmers working separately. They can work longer without getting tired, and when they're finished, two people undersand everything, instead of understanding just half of everything. (Extreme Programming Installed, 88)

Coding Standards

In general, mandating a strict set of standards from the top isn't a good idea. ...if there are going to be programming standards, programmers need to buy into them. (528)   We all code to an agreed coding standard. ... It doesn't matter so much what the standard is. What's more important is that everyone use it. (Extreme Programming Installed, 79)

The Planning Game

Have a walkthrough meeting for estimates. ... Have people estimate their own pieces, and then add the pieces together. (536)

  ...the developers sign up for the tasks they want to implement. As each developer signs up for a task, he or she estimates that task... (Agile Software Development: Principles, Patterns, and Practices, 21)

Re-estimate periodically. Factors on a software project change after the initial estimate, so plan to update your estimate periodically. As the project moves closer to completion, you can estimate better and evaluate your initial estimates. (537)

  It's not easy to guess how fast you will go at first, but it's easy to observe how fast you do go. (Extreme Programming Installed, 38)

When you plan the product initially, partition the product's capabilities into "must haves," "nice to haves," and "optionals." If you fall behind, prioritize the "optionals" and "nice to haves" and drop the ones that are the least important. (543)

  ...sort the stories into three piles: (1) those without which the system will not function, (2) those that are less essential but provide significant business value, and (3) those that would be nice to have. (Extreme Programming Explained, 90)

The plan is to embrace the unexpected and capitalize on unforeseen opportunities. (666)   Embracing change -- The best strategy is the one that preserves the most options while actually solving your most pressing problem. (Extreme Programming Explained, 38)

References


Home : Dave Hoover Copyright © 2001-2004 Red Squirrel Design, Inc. All Rights Reserved.