XP Revisited - Embedded.com

XP Revisited

None of the respondents to Firmware without a design? about Extreme Programming seem to have tried XP. After having been trained by Kent Beck, the author of Extreme Programming Explained, I've used XP on embedded and non-embedded applications for the last few years.

Producing a good design is central to XP. For a team using XP to be able to continue to be agile, it must keep the design in good shape. XP is an iterative development approach. An iteration (lasting two to three weeks) is essentially a full development cycle; some working features of the system are delivered with each iteration. The feature-driven approach means the architecture is explored early in the development cycle. Features cut across the architectural elements. In the iteration the code is specified, designed, written, and tested. These activities happen in parallel.

Test Driven Development (see Kent Beck's book) is a key practice to XP. It involves writing the tests and the code in a tight feedback loop. Design decisions are made to make sure the code is tested. The act of making the code testable enforces the decoupling of modules. It also encourages more cohesive modules. What are two attributes of a good design? High cohesion and loose coupling. A skilled XPer follows the rules of simple design (in priority order!):

  1. The code must pass all the tests — you know, the code has to work and deliver value to the user.
  2. The code must reveal the intention of the programmer — you have to be able to see what the code is trying to do.
  3. There must be no duplication — we've all seen the consequences of duplicating code and fixing a bug, only to find that the bug is still there. Or changing a requirement and then having to change the same code in many places.
  4. Fewest number of classes and method — don't get excited, these rules are in priority order. This is not encouraging giant classes and methods; it is encouraging not putting in architecture before it is needed.

The software needs to be fully covered by automated unit and acceptance tests. The system needs to be loosely coupled to allow parts of the code to be tested independently of other parts. The code must be written to be readable.

These techniques lead to well-designed code. Good design decisions are made a little bit at a time. When the code starts to get messy, it is not re-written, it is re-factored, a subtle difference. Working and fully tested code is moved around so that the design is improved, and still passes all the tests.

All software evolves — except for software no longer in use. User requirements continually change, driving more evolution. XP techniques are designed to deliver high external and internal quality in the face of continually evolving user requirements. An interesting side affect of using XP is that code development can begin very early in the project lifecycle, before all the requirements are known. We can start working on the most important requirements right away. This allows more of the team's effort to be applied to the solution over the life of the product.

Using XP will not guarantee a good design. Just like using RUP or waterfall will not. A good design comes from good people. XP is a collaborative development technique that can result in really good designs when there are some good people on the team.

James Grenning
Director of Consulting, and Extreme Programmer
Object Mentor, Inc.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.