Rickerism

I strongly support the Agile Development methodology for creating commercial software. There is nothing in the Agile Manifesto with which I would disagree. I have learned of late, however, that I do have a problem with Extreme Programming. No amount of methodology will make a bad engineer a good engineer. Whatever the initial intent of Extreme Programming, in my experience, I have only seen XP used as an excuse for bad engineering.

Extreme programming has a hole in it about the size of a barn door that Agile development does not. That hole is design. Extreme Programming states:

Let go of your notions of what the system should or should not be and try to see the the new design as it emerges before you.

XP instructs programmers to seek the simplest solution first, then refactor the design again and again. Some call it a “design-on-the-fly philosophy”. I call it crap. Such an attitude is not agile development; it is cowboy coding. It is an excuse for bad engineers to shirk their responsibility to design. People who write software code without a design are not engineers or developers or programmers, they are hackers.

XP developers talk about tracer bullets. From what I can gather, a tracer bullet is the quickest, shoddiest, half-ass job one can do and still pass a test script. No thought goes into the design of the code, how it is a part of a larger whole. That means the code must be thrown away at some point. Yet the code never is thrown away. It continues to live, grow and fester. Other code is written that depends on the first set of code. With the tracer bullet idea, it is simpler to hack the new code rather than changing the old code to a better design. Hack is built upon hack.

XP calls it a tracer bullet, I call it a cow path. It is a common belief that the tangle of Boston streets arose from paving meandering cow paths. Myth or not, Boston cow paths make a good metaphor. XP philosophy of expedience leads to paving cow paths. The old work is never fixed because the interdependencies of the code grow at an exponential rate. Without the forethought of good design, the interdependencies are more entangled that they would be otherwise. Releases become slower and slower because each change to one thing breaks ten others. Before management realizes the problem, the system has become such a tangled mess of spaghetti code that the whole thing has to be thrown out an redone.

The Agile Manifesto states:

Continuous attention to technical excellence and good design enhances agility.

Agile Development demands a higher level of competence from software developers. You cannot hide bad performance when you are shipping code on such a short, regular time interval. The openness of Agile Development is also a great mentoring environment, enabling junior engineers to see, hear and learn not only what is done but why it is done.

While XP sneers at design, Agile Development embraces design as essential. An XP team leader will tell developers, “Stop pestering me with questions. Fire a tracer bullet. Go off and make the simplest thing work.” An Agile team leader will tell developers, “This part of the code affects a lot of us. Let’s get on a white board and figure a good way to design it.” The team has an open discussion and achieves a collective understanding of the design requirements, the constraints, the alternative solutions and the chosen approach. The team leader will make a note of the design on the team wiki with a good line drawing.

If the problem is a big one, the team leader will draw a box around a section of the white board and say, “This part of the design we will implement now. The rest will wait till the next release.” This aspect is important. The design has anticipated future requirements and will to some extent accommodate those requirements. The code will be only what is necessary for the current release, but it will not have to be thrown out in the future release.