XP Is Not About Mindless Hacking

˜ ˜XP Is Not About Mindless Hacking!

The Extremos are quick to point out that XP is not an invitation to hack. So let s get that straight once and for all: XP is not about mindless hacking!

It s about jumping straight to code, having breezed over the design, doing the simplest thing that can possibly work, avoiding written documentation like the plague, and fixing up the design later during refactoring.

We think the difference should be clear to everyone.

Why Do XPers Feel That XP Is Not Really Hacking?

When seen up close, the XP way is all about discipline. XP practitioners have to be disciplined in order to follow the XP practices to the letter, for the duration of the project. Even the original XP team, whose members described themselves as the best software team on the face of the Earth and got book deals, had a lot of trouble sticking to the XP practices for their entire 4-year mission.

More about the original XP team in Chapter 2.

 

So it takes practice and dedication to be a true XPer. That doesn t sound much like hacking so far.

XP also involves lots of good things such as testing and planning. You wouldn t see these highlighted on a hack-and-whack practitioner s resume (actually, come to think of it, what do hack-and-whack practitioners put on their resumes?

Hmm . . .). However, as we explore in later chapters, XP also involves some not-so-good things such as not thinking beyond the current iteration.

We discuss in detail why not thinking beyond the current iteration is not such a good approach in Chapters 7, 9, 10, 11, 12, 13 to 15 inclusive, and in fact most of the rest of the book.

 

In other words, XP involves not designing for future requirements, not writing things down unless the customer explicitly asks for it, and asking the customer to define her requirements in scripted code (as acceptance tests).

Throwing Your Documents to the Lions

As XP becomes more socially acceptable in the mainstream programming world, parts of its Extremo culture are bound to spill over. In particular, the message that we no longer have to document our work is like throwing a tethered goat into a pit of hungry, ill-tempered lions. The hack-and-whack crowd will seize (and have already seized) this excuse to cease documenting their work and to leap into the code without spending time up front at least trying to come up with a decent design (and, of course, writing it down in detail and in a permanent form besides source code).

Although XP is clear about its reasons for not having a high emphasis on documentation (the theory goes that the risk is reduced by other practices, such as collective ownership), the danger is that no documentation will resonate with programmers who hate doing documentation. The danger is that in the future, more and more projects (both XP and non-XP) will fail, because all the reasons for documenting your design (and doing this prior to production coding) will have been forgotten about. The industry is in a lot of trouble already, but this aspect of XP really isn t helping.

Why Write the Design Down in Detail Before You Start Coding?

The process of writing a design down is itself a form of review. The process invariably causes programmers to uncover flaws, things that they just wouldn t otherwise have thought about, or just better ways of doing things ”and all of this before a line of code has been written. Documenting the design also allows senior engineers to review the design in detail. The documentation acts as a stake in the ground, so decisions made across numerous design meetings aren t misconstrued or forgotten about altogether.

There are even documented ways, methodologies, that explain how to increase the chances of getting your design right first time.

We explore some of these methods in Chapter 8.

 

With the advent of XP, however, these important methods are in danger of being forgotten, buried beneath the stampeding feet of elated programmers rushing to fling themselves upon the XP shrine and free themselves from the enslaving shackles of up-front design and written documentation. Call us old sticks in the mud, but these days, no one really seems to talk about trying to get the design right first time. Instead, everyone talks about refactoring their existing design ”wrongly thinking that they stand no chance of getting it right the first time and therefore shouldn t waste time trying. ^[1]

From requirements to design, XP appears to be about getting it wrong first, then correcting your mistakes as you go. Of course, you would never set out deliberately to get something wrong. But XP says that it s better not to spend very much time up front trying to get it right. This is why many people see XP as a license to hack.

^[1] One of the technical reviewers for this book pointed out that there are studies and maxims like Plan to throw one away (Brooks) that oppose this ”in other words, that writing code gives deeper insight into the design, hence the second version tends to be much better. This is absolutely true (although Brooks did say Plan to throw one away, not to throw code away each and every day!). The solution, then, is to enhance the design with early prototyping (which we cover in detail in Chapter 12). This speeds up the process, because you gain the insight into the design but without the additional delays associated with production code (e.g., you don t necessarily need to pair program or write unit tests for a prototype).