XP Engineering Practices

I've read several times that the methodology people use is Scrum plus the engineering practices from XP. In fact were loosely following this approach in our current project.

But exactly what are the engineering practices from XP? According to Extreme Programming Explained they are:

• Pair Programming
  • Write all production programs with two people sitting at one machine.
• 10 minute build
  • Automatically build the whole system and run all the tests in 10 minutes.
• Continuous Integration [1],[2]
  • Everyone commits to the mainline at least every day.
  • Each commit results in an automatic build and test of the system.
• Test-Driven Development [3]
  • Write a failing automated test before you write any code.
  • Refactor to remove duplication.
• Incremental Design
  • Invest in the design of the system every day. Strive to make the design of the system an excellent fit for the needs of the system that day.

Sounds easy?

The thing I've always liked about XP, is the specificness of the advice it gives. There's a balls out attempt to identify what best practice actually means. Most other methodologies are rather vague when defining what you should actually do - "it's context specific" they say. They're just not extreme enough I guess.

Of all the practices, the hardest one to pin down is incremental design. Fowler calls it evolutionary design and Ron Jeffries calls it simple design. Jeffries wrote down the simple design rules:

• Runs all the tests.
• No Duplication.
• Expresses developer intent.
• Minimises number of classes/methods.

Back on c2.com, the originating point of XP, they put it something like this:

Do The Simplest Thing That Could Possibly Work. Big Design Up Front is avoided because You Aren't Gonna Need It (YAGNI). Once the simplest thing is done, you Refactor Mercilessly, so that things are expressed Once And Only Once.

I think there's something incomplete about incremental design, as expressed here. For sure, most of the big design up front I've been involved with was overkill, and took nearly as much time as writing the code anyway. YAGNI speaks a definite truth. But, but. Sometimes you do need a bit of big design, for example the repository pattern for data access, and when you do you need to know which way your going.