A Case for Pairing: Open Workspaces and Distractions

I currently work as part of an agile mentoring team in a large organization. Up until recently, we shared a project room. At any given point in time, there might have been one of four to six or seven team members (including a manager), plus one to three people that we were working with. On average there were four people in the room at any given time.

Up until this experience, I had always had positive sentiments about open workspaces and team rooms. In this current setting, I did benefit significantly from getting to converse frequently with all of the other people in the room. I learned things I probably would never have learned otherwise. And, I had a grand old social time.

But I also found that I wasn’t getting much work done when I had things I need to concentrate on. It seemed like I could be guaranteed a distraction at least every five minutes. Either someone was asking a question, or I was overhearing something that I felt compelled to respond to. It got to the point where if I had to find a couple hours to work on something (such as preparing training material), I ended up leaving the open workspace to find somewhere quiet.

The problem wasn’t the open workspace, it was the fact that none of us were really working on the same thing. The other mentors were usually working on a different project than I was. And my manager, well, you know how managers are, there’s always something they want you to pay attention to right away.

Escaping the room on occasion was an adequate solution, but the better solution ended up being pairing. I noted that as soon as I found a partner to help build a solution, or someone that I was mentoring, the distractions disappeared. I surmise two reasons: first, as a pair we were focusing on a problem. That meant I was no longer listening to any external conversations. Second, people are more reluctant to interrupt two people that they see obviously engaged in a conversation or task.

As I’ve paired more and have worked with teams employing pairing, I’ve grown a long list of benefits that I’ve seen accrue from the practice. My experience here adds a new bullet item: pairing minimizes distractions.

Certification and the Agile Alliance

I attended a panel presentation, “To Certify or Not to Certify,” at Agile 2007 in Washington, D.C. The presenters included several esteemed members of the agile community, including (but not limited to!) Ron Jeffries, Michael Feathers, Mike Cohn, and Angela Martin. I thought the panelists offered some interesting but far from comprehensive thoughts on certification. The panel deliberately avoided “hot” or contentious questions, in favor of a subdued give-and-take on the topic.

What I heard was essentially this message: “certification is inevitable, so we should try to beat those other guys (whoever they are) to the punch.” Presumably, the interest would be to build good certification, so good that those greedy other guys don’t come up with poor certification. (The Agile Alliance issued a position paper on what they thought the value proposition was for certification; it can be found here.)

Shortly after the conference, I was invited to and joined an online action/discussion forum consisting of some of the aforementioned panel members. I asked for some goals for certification, thinking that there are many paths to many different kinds of certification. The first step toward any solution is knowing what the problems are, and how much of each problem you’re trying to solve.

If there is a discussion forum metaphor for blank stares, that’s what I got with my posts. A different action group formed, one where a decision was already made to build some sort of trust network (based on a notion similar to Google page ranks). I wasn’t so warmly invited to this second group. Perhaps my pointed posts helped kill the first certification forum.

Never one to be subdued by rejection, my response is to move forward on my own and establish a basis for a certification program for test-driven development (TDD). My intent is to produce a skill-based TDD curriculum, one about as rigorous as a typical university course. Is there a test? Is there a certificate? That’s probably not something I can build as a sole proprietor, but I’m open and ready to work on creating a standards body for TDD certification.

What are my motivations? They of course include profit, but they also include my strong interest in improving the level of professionalism in software development. While some decry profit motivations based on their belief system, certification schemes are primarily about profit, and I believe competition usually drives improvement. Let’s get competing!


Actually my nightmares will become a reality when certification in the Agile world comes. It’s close when you end up working for a moron with agile certificate, who knows shit about Agile software development – sorry, I couldn’t resist. It seams, it’s a time to create 4000 pages long agile process guide.

Right now, agile is “whatever Joe schmuck wants it to be,” for better or worse. To paraphrase the agile alliance folks, agile certification is coming, and their version of it is really going to suck.

I won’t bother if I think my version of certification is going to suck. If I certify someone, it will mean that I’m pretty confident that I would hire them, at least with respect to their TDD skills. If I can’t find a way to make that

I’m relatively new to the Agile world, but already I’m sick and tired of hearing to people who’ve read a book (any book) on Agile methods be a self-described expert.

I’m all for seeing a certification for Agile development. I’m curious to see if it would be biased towards any of the practices, or to general practices.

I think agile is interesting in that it doesn’t say all that much. That’s why it’s possible for the Scrum machine to offer a two-day class on Scrum. After talking about iterations, meetings, pigs, and chickens, what’s left? The challenge in agile is not in its mechanics but rather in learning how to solve problems (which are usually people problems) and improve upon such solutions regularly.

So I’ve decided for myself that at least TDD certification is valuable, because it is a demonstrable skill, whereas something like “general problem solving in an iterative context” is not so quantifiable.

To the anonymous who is new to the Agile world. Certification won’t make these people to shut up, actually I think they be first who get certified, so they could prove you they are actually an expert. Any discussion will end up with a statement “Don’t tell me I’m certified, so I do know how it should be done”.
Let me tell you an anecdote.
“The juggler was looking for a job and went for an interview to one of th circus. The CEO took a look at his resume and said:
– I see you have a juggler certificate. Can you juggle with 3 balls ?
– Yes, I can – replayed juggler.
– Can you juggle with 5 and more ? – asked CEO.
– Yes, I can – he replayed with a little smile.
– Great, that way I hire you – said CEO.
– But wouldn’t you like to see me juggling ? – asked the juggler.

Yes, I’m amazed at how we hire today. I’ve even had a number of people suggest that making people pair during interviews “just isn’t fair.” What, actually expect that they can demonstrate they know how to do what they’re about to be paid lots of money to do?

Still, we perceive some value in diplomas and university courses. I think there is value in the information that comes from close-knit interaction over several months, enough to say that “this person has potential.” Is a 15-week mentor/protege relationship be a sufficient basis for recommendation?


Agile Doesn’t Work If…

… you think it’s stupid. Or if you don’t want to do it. It should be obvious, but to truly succeed with something in life, you have to truly believe it’s worth doing.

As such, I’m going to suggest something to all the people out there who don’t think agile is a good idea: don’t do it. Please, find something better. Maybe you’ll hit across something we can all learn from. I’ll be happy to move on from agile once I see something better. Just remember that saying “I’ll do these kinds of things when I feel like it” isn’t agile.


Today, I received the following post on a few of my Yahoo group lists (refactoring, scrumdevelopment, etc.):

Greetings, everyone.

I apologize for the spam, but I wanted to share with you a new initiative on the web to help large organizations make the transition to agile. I have been working with several customers over the past few years, and their biggest complaint to me has been about scaling up their agile transition when it’s so expensive to find genuine agile experts. So many people have jumped on the bandwagon last year!

So we have joined forces with some large organizations, many of which you’d recognize, to take that first important step towards solving this problem. In the spirit of being agile, our first presence is small, but we’re growing it incrementaly, so I hope you will show us your support.

Please visit http://www.agilecertificationnow.com to become certified and spread the word. It’s easy!

John Smith

I highly recommend clicking through the certification links. You’ll also find a good letter from Tom DeMarco (which looks to be written in 1998) that talks about the value of certification.

The Great Loyalty Oath

Anyone who knows me knows that I have a good sense of humor. I’m usually the one in the back of the meeting room, making wisecracks and trying to keep a spirit of levity.

The Scrum(TM) development list this weekend has been rife with accusations about other people’s senses of humor. This is in response to Ken Schwaber, one of the Scrum founders, having promoted a secret handshake (which apparently is supposed to be accompanied by wolf howls).

Almost everyone has a sense of humor. What’s also true is that almost everyone has something for which they don’t have a sense of humor. In other words, they find offense in attempts at humor around these elements.

The best we can do is accommodate these peoples’ sensitivities. It doesn’t mean that we should stop doing the things that these people find offensive. If that were the case, half of human conversation would need to cease. Some people are just touchy about everything.

No, what “accommodate” means is that we don’t go out of our way to force our “senses of humor” on others. Telling dirty jokes in front of a religious person, when we already know better, is doing likewise. Making everyone howl like a wolf or touch one another in some potentially inappropriate manner is forcing our sense of humor. Simply put, it’s about showing appropriate respect. (Some people don’t find humor in anything–we best show these people respect by avoiding them, I suppose.)

I’m not offended by the whole thing, but I do find the whole “great loyalty oath” aspect of Scrum embarrassing. Not necessarily for the participants, but the for the whole of the “agile movement” (no, it’s not that kind of “movement”–that’s probably inappropriate humor, isn’t it?).

One thing that agile gets criticized for is the fanaticism of its proponents. I know, because I’ve been accused of being a fanatic. It’s an odd accusation, because anyone who has ever listened to me has heard me temper my statements, and suggest that these agile things we find valuable aren’t for everyone.

In any case, I have a hard enough time defending agile concepts to people who view them as childish and unworkable. This sort of unnecessary posturing just makes it all that much more difficult.

I do need to pause here and give credit to Mike Cohn. In his posting, referenced above, he explains it as “If we do something silly and a few people woof along with me, everyone remembers it”. I think that’s the right attitude. Unfortunately other peoples’ fascist tendencies (such as the other poster referenced above) lead them to look upon with disdain people who don’t feel like participating. We are branded as humorless and ostracized from the group.

I guess I don’t have the “right” sense of humor. My response, guaranteed to offend at least a few people, is at http://groups.yahoo.com/group/scrumdevelopment/message/19947.

We can do better. Instead of being indignant because someone dared resist the tide, we should look to find out what is turning them away. Instead of adding things to agile methods that are divisive and exclusive, what if we just concentrated on how to get teams to work together well? It’s really how great software gets produced.

“The important thing is to keep them pledging,” he explained to his cohorts. “It doesn’t matter whether they mean it or not. That’s why they make little kids pledge allegiance even before they know what ‘pledge’ and ‘allegiance’ mean.” – Catch-22

Practicing Programming

I was able to entice Ron Jeffries to speak at the Colorado Springs Agile Users Group (cosAgile) a few months ago. As usual, the talk was very entertaining. Ron, deck of 3×5 cards in hand, went through a number of topics, talking about “why software development is easy.” Or not.

One of the central messages was about practicing the craft of programming. Musicians do scales, professional sports teams have scrimmages, and firemen run drills. But most programmers I know don’t seem to practice much.

Or maybe they do, but I just don’t hear about it. There are gobs of open source projects out there, and geeks who just sit at home working on pet projects. Do these count as “practice?”

Ron is one of those guys who practices the bowling game, over and over, to see how his solution improves each time. I’ve done the same thing, working on building a database interface layer. It comes out a little differently and a little better each time. The last place I was at, we used this database interface layer as the basis for a weekly lesson in TDD.

CosAgile meets weekly to work on a password manager application, PeakPassMan. While the result will be a functional, usable product, that’s not the primary goal. The goal is for programmers to get together, share ideas, and work on a common source base while trying to learn more about things like test-driven development. CosAgile is certainly not the first group to promote the idea of getting together weekly to practice building code, but it sets a good, shining public example.

Practice makes perfect! Well, there is no “perfect” in programming, but honing your skills by practicing a problem is a great idea.

XP Pros & Cons: Reflecting on XP Experiences

A colleague in a graduate degree program recently posed a question to me on email:

> We’ve had quite a bit of eXtreme Programming discussion this week in my
> Software Processes class. Unfortunately, none of us have actually been
> involved in a real, live XP project. I’ve tried to defend it, but my XP
> background is pretty weak.
> I know you’ve been involved in a lot of XP work. Can you give me some info on
> what type of projects you’ve worked on, how successful they were, and what
> you think the pros and cons of XP are? If you don’t mind I’d like to quote
> you a bit in our online class discussion as someone who has really been in
> the XP trenches.

My response, with some name changes to protect the “innocent” and some additional cleanup, follows.

In general, the XP projects I’ve worked on were slightly more successful than the non-XP projects. I’ve probably coached 20 teams; this includes a mixture of small teams (2-4 people), lots of medium-sized teams (6-12), and a few large ones (18+). Some of the shop types included government, retail, airline industry, grocery, financial, telecommunications; everything was all over the map.

Prior to XP, I did lots of waterfall-based development at places like MCI, Marriott, and ChannelPoint [a failed Colorado Springs dot-com]; I also worked in a number of smaller shops where some flavor of waterfall was in place. I also did some spiral development at MCI, and I’ve consulted in a couple of shops where they had some implementation of RUP.

The most extensive XP effort I had experience on was with [a grocery chain I’ll refer to as IFC] in Texas, where I was initially in the trenches doing paired development. About two months after starting the contract I ended up running a short-term subproject to develop an offline solution for their pharmaceutical processing system.

The IFC effort was a good example of both success and failure in XP. Using test-driven development (TDD), the development team had managed to build a significant amount of reasonable quality production code within a short period of time. They reported a very low number of defects. The code had an extensive body of tests. The IFC team had an open environment and mandated pairing. However, there were a number of XP practices that the team did not follow. Specifically, they did not adhere to fixed-length iterations, and their planning was somewhat ad hoc; also, they did not refactor as much as necessary.

The upshoot was that at some point after I joined, they were unable to sustain reasonable delivery periods, partly due to some network dependency issues that exacerbated poor design in the code. Making changes to the code base was difficult, since the tests were overly dependent upon the implementation (they abused mocks). However, they were able to make a significant number of changes and improvements rapidly, since they had tests in the first place. Management insisted we develop an offline solution.

The offline solution I directed as coach/tead lead was to me a testament of the value of XP. In a matter of 8 weeks, we built a complete and successfully deployed solution that allowed offline pharmaceutical fills. As a coach with full ability to direct the XP team as I wanted, I took a number of “lesser” developers and showed them how to adhere to the simple rules that they had neglected over time: fixed iterations with simple but comprehensive plans, and hardcore as-you-go refactoring. The “senior” guys (including some expensive Vitria BusinessWare consultants) were left alone to solve the stability problems; they floundered and ultimately failed. My mostly junior team learned how to trust each other as a team (despite some early ugliness) and enjoyed working together. They also saw success and progress on a two-week basis.

I’ve seen many similar examples. At [a failed dot-com in Orange County], the development team continued to enjoy working on and delivering product while the walls and rest of the company crumbled around them due to a bad business model. At [a large company in Dallas], I worked with a number of different teams on a short-term basis; some of the teams had abysmal performance while others delivered spectacularly to expectation. The differences often could be attributed to adherence to practices.

The teams that took the values to heart and believed in what they were trying to do were successful. The teams who resisted and thought they were too smart for anyone else’s ideas on how to build things failed. Ultimately you could say this about most processes, not just XP. The best thing you can do is to get a team to gel: to learn how to communicate well and to trust each other. This means trusting each other enough to say when things aren’t going the right way. Or to speak up when something seems like it’s a waste of time (e.g. attending meetings where little is accomplished).

I believe XP promotes these values. If you want to talk specifics, the main value that I get out of XP practices boils down to three things:

  • testing/refactoring. These go hand in hand. Test-driven development (TDD) is the most valuable programming practice I’ve ever come across. The value of test-after pales in light of test-first. Refactoring is extremely important in extending the potential lifetime of software product; it is only really possible if you are writing comprehensive tests. And it’s really only effective if you do it all the time, i.e. if you build it into your TDD cycle (test, code, refactor, repeat).
  • constant planning. The problem with most projects is they attempt to plan once and assume they’re done with it. They spend a lot of time up front to come up with a date that everyone knows is bogus. XP takes the view that planning is good, but you really want to be planning and replanning all the time. Reality always intervenes with plans.
  • pair programming. Take a look at the article on my site called “Pair Programming Observations.” It contains a lot more information that I won’t repeat here. When done well, pairing is a wonderfully enjoyable and productive practice.

Here are what I consider the cons of XP:

  • As experience at IFC and elsewhere suggests, understanding and following through on quality design is essential. It is possible to depend upon “emergent design,” but if and only if you remain dogmatic about refactoring. A team needs at least a couple “refactoring zealots.” You have to eliminate duplication at all costs, and you have to ensure that the code remains expressive and clean. You have to write tests for everything. Tests are specs, and if you’re not going to write specs on paper, you have to write them in code. Write tests for everything, including exceptional conditions. Don’t write code unless there’s a test for it. Obviously you can’t test every possible condition, but you can at least test what you do know you have to code.

    The con here is that this is very hard to do. It requires a good coach to initiate and ingrain the rules into peoples’ heads. And it requires the people within the team to care enough to not let things get sour. Unfortunately, it’s almost impossible to get a team to be that meticulous. In retrospect, I’ve learned to invest just a small bit more of time up front in doing design. However, I temper that by ensuring everyone is fully aware that the initial design is a road map; reality will always take you on detours that end up redrawing your TripTik.

  • The temptation to let iteration deadlines slip is high. “Let’s just get that one more feature finished and then we’ll ship.” No. You have to learn to deal with deadlines in the small before you get anywhere near good at dealing with deadlines in the large. Management, unfortunately, has a hard time understanding this. So they slip. And then you lose all sorts of things, from consistency, trust, understanding of how to deliver product, and accuracy in estimates.

The pros:

  • Done well, XP gets a team to gel more than anything.
  • It builds true competency in all team members.
  • It makes for an enjoyable and honest work day.
  • It gets people out of their cubes and talking to one another.
  • TDD teaches developers about how to write quality code and how to improve their notions of design; it helps them to improve estimates. It improves the resumes of developers.
  • It gives management many tools, including predictability, flexibility of resources, consistency, and visibility into what’s really going on.
  • It gives customers the ability to see whether or not a company can deliver on its promises.
  • A personal favorite: you don’t spend a lot of time in stupid, wasteful meetings, and you don’t produce a lot of useless documents that no one reads and that aren’t trustworthy anyway.

With respect to TDD, the Jerry Jackson story about TDD is always good. I don’t remember if you’d ever met him while at ChannelPoint. He was one of the first authors of Java books; his book Java By Example was the fourth ever published on the Java language. I hadn’t seen him in a while; two years ago I met him in the fall while at Tim’s chess tournament. He said that he’d read a bit about TDD but hadn’t tried it yet, and that he was going to look into it. I saw him again about three months later, at another tournament. Before I could say anything to him, he walked up with his face lit up and said something like, “That TDD stuff is amazing!” This is the testament I get from anyone who’s given TDD an honest try. They all say similar things, about how cool it is and about how much it’s taught them about their coding and their design. Jerry now works at Cassatt; apparently they are all doing TDD (and a lot of their technique and inspiration is based off a paper I wrote for OOPSLA 2001).

Oh yeah… if you’re going to do XP, or RUP, or Scrum, or Crystal: Hire a process coach! It’s easy to screw any of them up. You would never field a football team without a coach, even if all of the guys had played before. It seems ludicrous that we slog away at building software, spending millions of bucks, without someone to make sure the process and techniques make sense.

I hope this helps.


What Are We Building?

Requirements, requirements. There are few things worse to me as a developer than having to guess what I’m supposed to build. I’m currently in a shop where we get high level requirements from an end customer, but the details are left to us.

–“Should this have a default, Bill?”
–“I dunno, what do you think, Jeff?”
–“I dunno, what do you wanna do, Marty?”

Ugh. It’s a huge comfort to have someone take the time to find out what we should really be building.

What Can Go Wrong With XP

Extreme programming (XP), on the surface, is a hot, trendy way of developing software. Its name appeals to the reckless and annoys the cautious (“anything extreme can’t be good!”). A recent article in Wired magazine attests to its popularity amongst the cool set, who believe that XP is a silver bullet. The article also talks about some of XP’s severest detractors, who view XP as dangerous hype. The truth lies somewhere between. XP alone will not save your project. Applied properly, XP will allow your team to become very successful at deploying quality software. Applied poorly, XP will allow your team to use a process as an excuse for delivering–or not delivering–low quality software.

Applying XP

XP is a highly disciplined process that requires constant care. It consists of a dozen or so core disciplines that must all be followed in order for XP to work. The practices bolster one another, and each exists for not one but for many reasons. For example, test-driven development and constant code refactoring are critical to ensuring that the system retains a high quality. High code quality is required in order to be able to sustain iterative, incremental development. And without constant peer review, many developers would quickly lapse from doing these critical practices. XP provides this review through the discipline of pair programming.

Yet many shops shun pairing, viewing it unnecessary for developers to pair all the time. Not pairing is not necessarily a bad thing, but in lieu of pairing, some other form of peer review must take place. (Fagan inspections are an OK second choice.) Without the peer review, code quality quickly degrades, and you now may have a huge liability that no one is aware of. The lesson is that if you choose not to do an XP practice, you must understand what you have just taken out. You must then find another way to provide what the practice brought to the table.

Good software development will always require these things:

  • planning
  • requirements gathering and analysis
  • design/coding
  • testing
  • deployment
  • documentation
  • review
  • adherence to standards

Contrary to popular misconception, XP says that you should be doing all of these things, all of the time.

Common Traps

The most common mistakes I’ve seen in the application of XP include: not creating a dedicated customer team, not doing fixed iterations, misunderstanding test-driven development, not refactoring continuously, not doing design, and not pairing properly.

Not Creating a Dedicated Customer Team

If you read earlier literature on XP, you will be told that there is one customer for an XP team. The practice was called “On-site Customer.” Since then, Beck and others have clarified this practice and renamed it “Whole Team.” The whole team aspect is that we (developers and non-developers) are all in this together.

The customer side of the fence has been expanded to include all people responsible for understanding what needs to be built by the developers. In most organizations this includes the following roles.

Customer / Customer Proxy In most cases, the true customer (the person buying and using the system) is not available. Product companies have a marketing representative that understands what the market is looking for. The customer or proxy is the person that understands what the functionality needs to be in the system being built.
Subject Matter Experts Used on an as-needed basis.
Human Factors Experts Developers are good at building GUIs or web applications that look like they were built by… developers. The user experience of a system should be designed and presented to the development team as details to stories presented at iteration planning.
Testers Most customers have neither the background nor the time to define acceptance tests (ATs), which is the responsibility of the customer team. Testers work closely with the customer to build specific test cases that will be presented to the development team.
Project Managers While a well-functioning XP team has little need for hands-on project management, project managers in a larger organization play a key role in coordinating efforts between multiple projects. They can also be responsible for reporting project status to management.
Business/Systems Analysts Customers, given free reign, will throw story after story to the development team that represents addition of new functionality. The development team will respond well and rapidly produce a large amount of functionality. Unfortunately, other facets of requirements will often be missed: usability, reliability, performance, and supportability (the URPS in FURPS).

In an XP project, it is debatable as to whether these types of requirements should be explicitly presented as stories, or should be accommodated by functionality stories. I’ve seen the disastrous results of not ensuring that these requirements were met, so I recommend not trusting that your development team will meet them.

The business or systems analyst in an XP team becomes the person who understands what it takes to build a complete, robust system. The analyst works closely with the customer and/or testers to define acceptance tests, and knows to introduce tests representing the URPS requirements.

Note that these are roles, not necessarily full-time positions. Members of the development team will often be able to provide these skills. Just remember that the related work comes at a cost that must be factored into iteration planning.

Not Doing Fixed Iterations

Part of the value of short-cycle iterative development is the ability to gather feedback on many things, including rate of development, success of development, happiness of the customer, and effectiveness of the process. Without fixed-length iterations (i.e. in an environment where iterations are over when the current batch of stories is completed), there is no basis for consistent measurement of the data produced in a given iteration. This means there is also no basis for comparison of work done between any two iterations.

Most importantly, not having fixed iterations means that estimates will move closer to the meaningless side of the fence. Estimating anything with any real accuracy is extremely difficult. The best way to improve estimates is to make them more frequently, basing them on past work patterns and experiences, and to make them at a smaller, more fixed-size granularity.

Putting short deadlines on developers is painful at first. Without fixed deadlines, though, customers and management are always being told, “we just need another day.” Another day usually turns into another few days, another few weeks. Courage is needed by all parties involved. Yes, it is painful to not finish work by a deadline. But after a few iterations of education, developers learn the right amount of work to target for the next two weeks. I’ll take a few failures in the small over a failed project any day.

Misunderstanding Test-Driven Development

Small steps.
Small steps.
Small steps.

I can’t repeat this enough. Most developers that learn TDD from a book take far larger steps than intended. TDD is about tiny steps. A full cycle of test-code-refactor takes on average a few minutes. If you don’t see a green bar from passing tests within ten minutes, you’re taking too large steps.

When you are stuck on a problem with your code, stand up and take a short break. Then sit down, toss the most recent test and associated code, and start over again with even smaller steps. If you are doing TDD properly, this means you’ve spent up to ten minutes struggling; I guarantee that you’ll save gobs more struggling time by making a fresh attempt.

Tests are specs. If you do test-driven development correctly, there is no code in the system that can’t be traced back to a spec (test). That means that you don’t write any code without a test. Never mind “test everything that can possibly break.” Test everything. It’s much harder to get into trouble.

As an example of a naive misunderstanding of TDD, I’ve seen tests that look like this:

public void testFunction() {
   SomeClass thing = new SomeClass();
   boolean result = thing.doSomething();

In the production class, the method doSomething is long, does lots of things, and ends by returning a boolean result.

class SomeClass {
   boolean doSomething() {
      boolean result = true;
      // lots and lots of functionality
      // in lots and lots of lines of code
      // ...
      return result;

Of course, the test passes just fine. Never mind that it tests none of the functionality in the doSomething method. The most accurate thing you could do with this code is reduce the doSomething method to a single statement:

boolean doSomething() {
   return true;

That’s all the test says it does. Ship it! 😉

Test everything until you can’t stand it. Test getters and setters, constructors, and exceptions. Everything in the code should have a reason for being, and that reason should be documented in the tests.

Not Refactoring Continuously

Understanding how to approach refactoring and do it properly is probably the most misunderstood aspect of XP. Not refactoring well is also the quickest way to destroy a codebase, XP or not.

Refactoring is best viewed as the practice of being constantly vigilant about your code. It fits best as part of the test-driven development cycle: write a test (spec), write the code, make the code right. Don’t let another minute go by without ensuring you haven’t introduced junk into the system. Done in this fashion, refactoring just becomes an engrained part of your every-minute every-day way of building software.

As soon as you aren’t on top of it, however, code turns to mush, even with a great design.

XP purists will insist that constant, extreme refactoring allows your design to emerge constantly, meaning that the cost of change remains low. This is absolutely true, as long as your system always retains the optimal design for the functionality implemented to date. Getting there and staying there is a daunting task, and it requires everyone to be refactoring zealots.

Many shops experimenting with XP, however, understand neither what it means to be a refactoring Nazi nor what optimal design is. Kent Beck’s concept of simple design can be used as a set of rules. The rules are straightforward; adhering to them takes lots of peer pressure.

Not Doing Design

I’ve heard far too many people saying that “you don’t do design in XP.” Hogwash (and I’m being nice).

As with everything else in XP, the “extreme” means that you do design all the time. You are designing at all sorts of levels. Until you get very good at following all the XP disciplines, the iteration planning meeting should be your primary avenue for design.

Iteration planning consists of task breakdowns. The best way to do task breakdowns is to start by sketching out a design. UML models should come into play here. Class diagrams, sequence diagrams, state models, and whatever other models are needed should be drawn out and debated. The level of detail on these models should be low–the goal is to solve the problem of general direction, not specify all the minute details.

For a typical two-week iteration, a planning session should last no longer than half a day (how much new stuff that needs to be designed can possibly fit into two weeks?). But if you’re just getting started, and the design skills on the team are lacking, there is no reason you can’t spend more time in the iteration planning meeting. The goal should be that you spend less time next iteration.

Design should also be viewed as a minute-to-minute part of development. With each task tackled, a pair should sketch out and agree on general direction. With each new unit test, the pair should review the code produced and determine if the design can be improved. This is the refactoring step. Ideally you’re not seeing large refactorings that significantly alter the design at this point, but things like commonality being factored out into a Template Method design pattern will happen frequently.

At any given time, all members of the development team should have a clear picture of the design of the system. Given today’s tools, there is no reason that a detailed design snapshot can’t be produced at a moment’s notice. In fact, I highly recommend taking a snapshot of the existing system into the iteration planning meeting to be used as a basis for design discussions.

In XP, design is still up-front; it’s just that the increments are much smaller, and less of it is written down. In a classic, more waterfall-oriented process, more design is finalized and written down up front. The downside in XP is that there is some rework based on changing requirements. The downside in the classic process is that there is no such thing as a perfect design, and following an idealistic model results in overdesigned and inflexible systems. There are always new requirements, and a process that teaches how to be prepared to accommodate them is better than one that does not.

Not Pairing Properly

Part of pairing is to ensure knowledge sharing across the team, not just amongst two people. Ensure that your pairs switch frequently–at least once per day if not more often. Otherwise you will get pockets of ability and knowledge. Corners of your system will turn into junk, and you will have dependencies on a small number of knowledgeable people.

Developers will resist switching pairs frequently. It is a context switch, and context switches are expensive. If you are in the middle of a task, and the person you were working with leaves only to be replaced by someone else, you must take the time to get that person up to speed. Frequent pair switching forces you to get good at context switching, which forces you to improve your code maintainability. If your code is poorly written and difficult to understand, the newly arrived pair will waste far more time getting up to speed. Ideally, the new pair should balk and insist upon more code clarity before proceeding.

The ability to quickly understand code and associated unit tests is what makes software maintenance costs cheap and consistent. Maintainable code is what allows you to be able to sustain the quality of your system over time.