Refactoring Heaven

In essence, much like sentence first, verdict afterward from Alice s trial in Wonderland, it s code first, design afterward in XP. Stuff and nonsense ! The idea of writing the code first! seems pretty applicable to us.

Refactoring itself isn t a bad thing, but it does, in our opinion, make a very poor substitute for design. Assuming that the only way or the best way to achieve a clean design is to refactor code is to ignore the benefits of techniques such as UML sequence diagrams. These techniques can be amazingly effective in helping you to come up with a good factoring of your design in the first place. The Extremo mind-set relegates these techniques to the scrap heap, the justification for which seems to be that the Extremos don t know how to use them effectively.

We believe that a more efficient approach is to make a reasonable attempt at doing a good design before jumping into code, and then use refactoring to catch the (hopefully few) design errors that slip through.

There are a few other troubling aspects to the widespread adoption of refactoring as a replacement for design, not the least of which is performance to schedule. Remember that the definition of refactoring involves making no changes to the external behavior of the code. You re just rearranging the internals to make the code smell better. ^[2] Keep in mind that according to Extremo theory, the code you re refactoring has already passed all of its unit tests and scored 100%. So the code is already right in terms of producing the correct results, we re supposed to assume. Yet, even though it ain t broke, we re gonna fix it. And when do we stop fixing it? When it smells good! Yeah! Makes us feel like singing .

A Day in the Code

(Sing to the tune of A Day in the Life by The Beatles)

I smelled the code today, oh boy
It smelled of pink champagne and strawberries
An architecture had emerged
And I just had to laugh

He wrote it on an index card
He didn t know that the requirements changed
So when he ran his unit tests
The gold owner became distressed

But we re still Coding On

I heard the news today, oh boy
The payroll project had just gone away
The code was really just a mess
But you must remember termination can be success

The hype goes on
And
On

Occasionally we wonder . . . what if the code smells like . . . grapes, but we re sort of looking for a strawberry essence to waft gently into our nostrils when we smell the code? Is refactoring to suit olfactory preference in this fashion considered good practice in our brave new world?

Key to making this whole refactor-instead-of-design equation work (well, sort of) is the fact that XP contracts are always variable in scope and schedules are never fixed (not even when there are 76,000 employees who might not receive a paycheck, it would seem). In the XP world, software is never done (presumably this is because you can always find another way to rewrite it).

This strange , bizarro-world parallel universe where software is never done, although undoubtedly a blessing to programmers who are getting paid by the hour with no end of the project ever threatening to end the gravy train, is a very foreign concept to the intrepid authors of this book. When on a programming assignment, we ve always assumed that our job is to actually get the client s job done, and get it done as soon as possible (within reason). So we invest a little bit of time in up-front design and then do our damnedest to write the software right the first time. And most of the time (astoundingly) we re able to do a pretty good job at this. We re not infallible ”once in a while the design might not be as clean as we d like because we learned something along the way or because a requirement changed on us. When this happens, we re happy to use the refactoring techniques to improve the quality of the code.

Heretical and stodgy as it sounds, we think we should use requirements analysis techniques such as use cases to help us figure out what we re going to build; use design techniques such as sequence diagrams to help us do a good factoring of the design; and then code it, test it, and use refactoring techniques to do further cleanup if necessary. And we should get the freaking software done on schedule. ^[3]

But the Extremos advise us that we shouldn t invest time in up-front requirements analysis and design. Rather, they say we should code the simplest thing that can possibly work, ask us to believe that turning a blind eye to future requirements and coding the simplest thing that can possibly work with a focus on only the bit we re working on at the moment is somehow different from hacking, and then tell us to plan on refactoring it on pretty much a continuous basis. Small wonder that software is never done in the Extremo universe. Look, Martha, we ve invented a perpetual coding machine.

What we can t understand is why a client would ever knowingly go for this approach. The key word in that sentence being knowingly. Which pretty much explains why we ve written this book, come to think of it.

^[2] Originally presented at UMLWorld as part of Doug s Alice in Use Case Land keynote speech. The full text is available at http://www.iconixsw.com/aliceinusecaseland.html.

^[3] Extremos often claim that XP helps to bring software in on schedule because they keep revising the schedule in each iteration ”in other words, they have schedule, but the schedule doesn t exist per se. And if the team encourages the customer to embrace scope creep, they can just keep adding features as they go, revising the schedule ad infinitum, until the project gets cancelled. More about this in Chapter 11.