At the End of the Day

The problem with life is that there s an answer to everything. Not an answer for everything, though. For any argument that someone wants to make, it s possible to find a credible source and quote it to prove his point. Studies are performed that prove just about anything that needs to be proved. Further studies prove that the previous studies got it wrong, and so on. Studies are even performed that question the effectiveness of studies.

It doesn t take a sophisticated understanding of the Heisenberg uncertainty principle to appreciate that whoever commissions the study influences the result. Eventually, personal experience and your own set of values turn out to be a much more valuable orienteering kit to help navigate your way through the moors of conflicting advice, where cheery voices shout at you from out of the gloom, There s a study that proves my point, you know!

It s a complex world out there, and you would be forgiven for sometimes thinking that methodology authors are trying to shove their opinions down your throat. ( Swallow that bitter pill! ) Of course, this book is no different. If you ve reached this point ( assuming you didn t just skip to the last chapter to find out who the murderer was), you might feel that we re just as guilty (probably more so) of being opinionated and trying to shout those opinions onto others.

Whether you agree or disagree with our arguments in this book probably has more to do with your own experience and reflection on life (i.e., whether our arguments resonated with your own opinions and experiences of projects past). It s likely that you set out to read this book with your mind already made up regarding XP. That s okay ”it s part of being human. People very rarely change their minds about something as fundamental to the human psyche as how to develop software.

Not everything about XP is bad. In fact, XP has achieved many good things for the software industry. It has introduced the concept of refactoring to a wider audience, and it has helped to boost this concept even outside the XP world. It has also enforced key disciplines such as design simplicity, modularity, code conventions, and so forth that are not exclusive to XP, but about which it always helps to evangelize.

In fact, when we get right down to it, there is nothing particularly new in the individual parts of XP. The practices all existed before in various corners of the industry, and some of what XP preaches is even preached as good practice in the nonagile parts of the industry. What makes XP unique, though, is the combination of practices that its creators have put together into one process and the established practices that the XPers have chosen to leave out or modify almost beyond recognition. This is summed up rather nicely by David Van Der Klauw (who we have quoted in the Voice of eXPerience sections throughout this book):

Imagine how angry Christians would be if I took the Ten Commandments from the bible, added two of my own, packaged it as a new religion, and then used the merits of the original ten to justify my additions. Something similar, I believe, is what has happened with XP. ^[14]

XP has sparked some interesting debates about how software should be created, something that is really quite important for the software industry.

It has achieved these things with more than its fair share of controversy, for a number of reasons. Two of these reasons are as follows :

• Instead of simply using key disciplines to strengthen it, XP makes them a core part of its methodology, such that it relies on them in order for it to work. This sounds great, but it s then an anorexic process without effective contingency plans.

• Amid the good advice, XP also contains some bad advice. That is, it contains advice that doesn t make sense outside the XP world.

Eventually, only you can decide what to do next . It s your project. We re not empowering you with this; it s just the way it is. However you decide to proceed (with XP, without XP, with only parts of XP), having listened to both sides of the argument and weighed the advice objectively, it s important to base the decision as much on your own gut feeling as on the opinions of others. Don t be taken in by all those impressive-sounding studies, though. Their experiences are their own. Yours might be similar, or they might be 100% different.

Perhaps that s why we ve found ourselves to be so opposed to XP (even though XP s agile goals are about right). We ve found our experiences to be wildly different from those of the XP authors. For example, they say (largely speaking) that project inception activities, requirements elicitation , fixed-scope contracts, detailed upfront design, and a decent change-management system (including traceability) are tiresome, optional, and too time consuming for most projects. On the other hand, we ve found that these exact same things save projects . In most cases, these activities are essential to the initial and ongoing success of your project.

It s possible to denigrate these activities by saying that they re based on fear. We prefer to say that they re based on simple common sense. With the increasing number of XP projects that are being started, some of these projects will, of course, succeed. The risk is high, though. All these projects will be flying by the seat of their pants. XP claims to have a safety net in the form of unit tests. Even patched with XP s other practices, that s hardly sufficient to prevent most real project-failure modes (see the analysis of C3 in Chapter 2). Trying to reduce software development to a simplistic, naive formula based on one (dubious) success and then designing a methodology around it is bound to create problems and contradictions.

L istening, T esting, C oding, D esigning. That s all there is to software. Anyone who tells you different is selling something. ^[15]
”Kent Beck

^[14] Ibid., back cover.

^[15] David Van Der Klauw, e-mail to author, May 2003.