XP Installed- Chapter 10-12

Ye' Ain't Gonna Need It!

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson

Todays XP Installed reading chapters are "Quick Design Session", "Programming", and "Pair Programming".

Chapter 10 was nice, with its being one page and all. I support one page chapters. It covered the basic concept that once a story is broken out into tasks, on average the way to implement the task is blindingly obvious. In the few cases that it's not, it's suggested that you sit down with a few folk, and go through traditional design exercises to get a better feel for the problem. After the first ten or fifteen minutes the design session should start to involve code, as a means of "grounding" it; as past those initial ten minutes design sessions start to wander... alot.

Chapter 11 talks about programming. It starts with the basic tenets of Test Driven Development and Pair Programming, then talks about some of the more fundamental ideals. It talks indirectly of the KISS, DRY, and YAGNI principles, followed by refactoring (ie changing the structure of the code / removing what are now your design mistakes) and continuous integration (keeping all the parts of a system constantly together). It then talks about coding standards (having one, specifying formatting and general naming standards), the horrible things that can happen in long bouts of overtime. This chapter is followed by an interlude expanding on the KISS, DRY, and YAGNI principles (not called out by name), and the idea that one goal is to minimize the amount of code in the system.

Chapter 12 is on pair programming. The basic concept is you have a driver and a back seat driver (or partner...). The driver does most of the typing while keeping a conversation about what she is doing with her partner. The partner in turn is granted the wonderful ability to think about what is going on without the need to type. This can lead to different solutions between the pair, and constructive dialog. It's generally better if the person with the least idea of how everything will turn out is the driver, as it prevents someone with low understanding from just casually agreeing, while also ensuring a certain amount of knowledge transfer. One other tenet for Pairing is switching off on occasion, either every few minutes, or finding points where an interruption is worth while. Basically, Pairing is about the interaction between the two programmers, ensuring that one doesn't own the entire code base, that both understand what is happening, etc.

Das ist alles!

Discussion:

1. Why is this paper interesting or significant?

Provides a description of the development process in an XP environment. Finally something not specific to either managers or customers! Yay!

2. What are the faults of this work?

It's not to so much faults in the authors work as in the process. Or alternatively these are faults in my past work and experience. My experience has led me to the conclusion that XP is well suited for simple, "6 months + maintenance" business applications, but not much else. 

The TDD cycle tends to build a very large test base, (a code glut), which depends to an extent on the internal workings of objects. This make refactoring and restructuring much more difficult. Small class/method count designs might not be readily testable, and testable designs can often turn out more convoluted then worthwhile. Especially where the database is concerned. That gods damned database...

The YAGNI principle, while in theory will lead to better code, can also tend to spiral out of control due to incremental additions. Once increment after another after another over time will lead to a design thats not quite clearly comprehensible. In theory this is handled by refactoring and programmer guilt, but in practice deadlines prevail and technical debt is accumulated (and rarely repaid)- once something works, going back and fixing it is rarely more important then getting the next new feature in.

Basically, XP as outlined in these chapters is good for quick, rapid development with minimal expected maintenance, but my experience is that teams wander away from it on large multi-year, multi-evolution projects.

3. What is the possible future work extending from this work?

In theory, pair programming would be the basis for "our team doesn't have a single point of failure". As far as the projects are concerned, several of the core principles (YAGNI, DRY, KISS, low_code) should apply quite nicely.