Maybe it's just the name: Extreme Programming. Maybe it's something we said. Whatever the cause, there are lots of misconceptions about XP. From time to time we'll try to correct some of them here.

Thinking

First and foremost, XP is intended to be applied by thoughtful, thinking, human beings, not some kind of mindless robot. While the XP “rules” are expressed very directly and in no uncertain terms, and we do recommend that teams just beginning with XP do the practices exactly, all the time, the point is to do things in these new ways, and learn from the feedback.

Sometimes, seeing that the rules are so vividly presented, people conclude that XP is rigid and against thinking. Nothing could be further than the truth. XP is a humanistic discipline of software development. It’s about people, it’s for people, and it is trying to work in ways that people find comfortable and effective. I myself do not like to be told what to do, and I try hard not to tell other people what to do. It seems only fair.

XP says that “all production code is written by two people sitting together at one machine”. That’s the rule. As far as I know, no project has ever done that, including many that I consider to deserve the name XP. So what’s the rule about? It’s an ideal. It’s what we strive for. It is a stretch goal. Kent likes to say Extreme things. I just go along with it because he likes to; I myself am quite conservative in expression as all my readers know.

I say “do the simplest thing that could possibly work”. Kent asks “what is the simplest thing that could possible work”. Do we really expect that you’ll forget everything you know about parsers or EJBs or relational databases? Of course not! We do want you to think about using smaller, less-powerful and simpler tools before bringing out the big guns. Fifty web pages need some kind of organization, I know. But they probably don’t require quite the same amount of structure than Amazon needs for their thousands. As technologists, most of us revel in our ability to handle complexity and love to learn the latest new thing. We need a reminder that our job is to produce simple, maintainable programs, Real Soon Now, not to build giant enterprise software to support a few web pages.

We say “YAGNI”, “you aren’t gonna need it”, to remind ourselves not to add features to the software just because we happen to be passing through and think of it. We do that because

  • deciding which features we work on is a business decision, a Customer decision in XP, and we want to make sure they get to decide;
  • we often guess wrong about how to do the idea we have;
  • it's usually no harder to put in later, and often easier, so money spent now could be spent later with just as good an effect.

So we say YAGNI to remind ourselves of these facts, and to bias ourselves strongly toward simplicity. We trust that we’ll use all our knowledge and wisdom to apply simplicity wisely.

XP is for Skeptics

Simplicity, communication, feedback, courage. Team members who know things, and are skeptical about how XP will do things have an opportunity to work in a simple environment, communicate their ideas, and get feedback on how well they work. Have courage, skeptics, XP is for you, too.

XP says lots of extreme things. The purpose of each and every one of them is to get us thinking in a direction which is different from our ordinary way of looking at things. XP is about thinking, and it’s about thinking differently.

Documentation

The XP literature makes few if any specific recommendations for documentation that projects must do. And we do say that programming teams that work together, with pair programming and collective code ownership, need less documentation for themselves than teams that work further apart in space or time.

People conclude that we are against documentation. This is not, repeat not, the case. We are against unnecessary documentation – but of course everyone is. People who haven’t worked in XP style are often concerned that internally to the team more documents will be needed, based on their experience working in other styles. Well, they’ll find out when they try it. And see also the discussion here on thinking.

I’ve written about documentation at length here, and will let those articles stand on their own. Here’s a summary observation: XP says that the technical people should make the technical decisions and the business people should make the business decisions. That’s Programmers and Customers to us. Therefore,

  • Internal documentation in the course of the project is a technical decision. If the programmers need it, they are expected to do it. And we trust, see thinking above, that they will notice that they need it, and do it. We expect that much of the documentation they'll do will be lightweight, ephemeral. Whiteboards and scraps of paper are very common tools for this purpose.
  • Everything else, whether manuals or maintenance documentation or filings with the government, is produced for some business purpose: helping users use the program, maintaining the program in the future, satisfying regulations, and so on. Since these documents are needed for business purposes, the decisions about them belong, according to XP's division of responsibility, to the Customer role.

That’s the rub, in the minds of some critics. For example, they know, quite rightly, that maintenance documents will be needed when the program is handed over to new programmers to be maintained. And since we don’t say that the programmers should just go ahead and write these documents, they think bad things will happen.

Well, we don’t know when or how you are going to hand off your project, and we don’t know what documents you’ll need to do it. Are you going to just trim the team and leave some of the original players in place to maintain it? Then you’ll need very little. Are you going to bring the maintainers in six months before the original programmers leave and pair with them? Then again, you’ll need very little. Are you going to ship the program to Bangladesh for maintenance? Then you’ll need a lot. In every case, the amount you need is a function of how good your code is, what your hand off process will be, and in every case it’s a business decision. It is a business decision that needs to be informed with technical input, and – yes – we do not give much advice on how to do it. But see also Business / Technical Communication below.

We may at some future time say more about these matters. For now, we haven’t said much. What we have said is that we understand that you’ll need documents, and that the way XP works, many of them are business decisions. That makes them Customer decisions in XP terms. We trust that you’ll figure it out.

In particular, we trust that the people who are doing all the complaining will figure it out. Why they don’t just say what they would do and be comfortable, I’m not sure.

What’s a bit ironic is that some of the folks who object hold such strong opinions that I’m sure they’d make themselves heard on a real project. As we’ll discuss just below, the process is open to thinking, discussion, and modification based on what folks know and believe. XP isn’t trying to tell us everything, it’s trying to adjust our thinking in a slightly different direction.

Business / Technical Communication

Sometimes people are concerned about the business / technical split in XP. Typically they are technical people who think they know something about the domain, and often they are right. Sometimes we technical people do know more about the domain than the designated Customer. Well, then, doesn’t that mean that we should make some of the business decisions?

It would be perfectly OK to define a methodology that worked that way. It just wouldn’t be the one that we wanted to define. We have observed that technical teams that decide what’s good for the customer typically build too much, and the customers all too often don’t like it when they get it. So even though it is more work for the customer – and it is – we recommend having the customer fully engaged in the process, making all the business decisions about what to do, and what to defer.

Doesn’t this mean that they’ll make mistakes? Sure it does. Like you and I wouldn’t make mistakes? Like we don’t? Of course people will make mistakes. That’s why XP is focused on teams being together and on lots of concrete feedback, so that people will learn as quickly as possible.

But what if the customer is about to make a mistake and we technical people realize it? That would be bad!

No, actually, that would be good. Watch a good baseball team operate in the field. Everyone backs up everyone. Similarly in your XP team, everyone with an idea should get it heard. If the technical people know something that the customer needs to know, they should – wait for it, this will be a shocker – they should tell the customer. Yes, actually talk to them, inform them. Then let them decide.

The XP values are simplicity, communication, feedback, and courage. They apply directly to this situation. The simplest thing to do is to communicate directly between the people who are commited to the project. So we have them all come together all the time. When the decision maker decides, we ship software every two weeks, so that they can see the results of their decisions in time to learn. And we recommend that the team should have the courage to try this to find out how well it works..

Have courage. Your customer isn’t stupid, though she may not know everything you know. Have a conversation with her. Two of you have a great opportunity to learn something.