TDD: The Rhythm

Good TDD, well real TDD, provides the team with a heartbeat.

Everyone has a heartbeat, you know what it's like: continuous and clear, smoothly flowing, subtle yet ever so present and soothing. Its unlikely that you're explicitly listening to it, but you are without doubt subconciously aware of the supreme comfort and reassurance that heartbeat provides you each and every minute of your day. It keeps you alive!

Same is true with software development. And while Iterations, Stand-ups, and CIT no doubt provide an essential macro-heartbeat, those things aren't what give us that minute to minute assurance analogous to our human heartbeat. That's where TDD comes in - true TDD provides us that comforting development heartbeat to actually get us productively and happily through the day.

It provides the transition from story card to failing storytest (acceptance test). Then from failing storytest to the first failing microtest (unit test). Then minutes later to the first passing microtest. Then minutes later to the next failing microtest, then the next passing microtest, and our first refactoring. Then minutes later to our next quick cycle of "red/green/refactor". Then within an hour our first check-in. Then a few more "red/green/refactor" cycles and another checkin. And before you know it, after one of those cycles, boom, a passing storytest! A high-five and a final checkin, then home by 6 to see the kids.

Do you hear it? Thum-THUMP, Thum-THUMP, Thum-THUMP...RedBar-GREENBAR, RedBar-GREENBAR, RedBar-GREENBAR...
A development heartbeat.

It's this rhythm that guides you, that keeps you on track. Its what gives you the constant feedback to know, at every step of the way, that you're growing the right design, that you're satisfying the customer's needs, and that you haven't broken any windows. It's what allows you to move freely and move fast. It's this rhythm that makes you feel good. It's this rhythm that makes you feel alive and happy.

Ask anyone whose felt it. Once you've actually truly experienced this rhythm - this heartbeat - I assure you, just as with your human heartbeat, you'll find it unbearable to ever live without.

Doing The Right Thing And Getting It Done

Been following my man Corey as he moves along on his Journeyman Tour (which I posted about on InfoQ at its onset), in fact had dinner with him tonight!

Here's a talk he did recently on "Practice", which I'm totally in agreement with. Check it.


Practice - Corey Haines from 8th Light on Vimeo.

Keep on keepin' on, Corey!

Killing "Quality"

So, a guy walks into a bar...

No, just kidding. But seriously though...

You walk into a bar and order a "low quality" beer (tough economy these days). What does this mean to you? That it'll come out with a bug swimming in it? That it will be served heated up? That it will be skunked? Glass only half full?

No, of course not. You'd be appalled, outraged. Have every right to ask for your money back. This place has acted in bad faith, they've acted unacceptably. You leave angered and vow to never return.

Your wife wants you to drop $600 on a new Louis Vuitton bag (you gotta buy cheap beer and she' still asking for Louis?!?), because it's a "top quality" product. Does she describe it this way because she knows it has less likelihood of falling apart the minute she gets it, or its colors smearing, or it having holes in the bottom? Again, no. These things are assumed to be absent. In the rare case you do happen to find anything like this, you are sure to invoke "return to sender, no questions asked".

I could continue on this way throughout various types of products, but I suppose you get the point.

Well, this ain't the case with our industry (Software Development). So I ask ye: WTF, man?

We use the word "quality" as an indicator of both "value" and/or "defect" presence, interchangeably.

When someone says "high quality" they could very well be talking about the absence of defects or they could be talking about the presence of value. And by software standards, neither would be an inappropriate use of the word.

Not so in the bar, not with your beer. Why then for us? Again I ask, WTF?

I know, I know. Some of you are sitting there saying (correctly), "hey, wait, agile pays attention to customer feedback to iterate towards a higher quality solution. We're talking about 'value presence' there." Or maybe your saying, "Our company's website says 'highest quality product in the industry!'. That's talking about 'value presence' too! That's what we mean when we say 'quality'."

Well, maybe so (and good for you, seriously). But I bet many of you still call your testers "the QA folk". "QA", as in Quality Assurance, as in "Those who ensure quality". But really, is their (primary) function that of ensuring 'value presence', or of ensuring 'defect absence'? Look, don't get me wrong, on a healthy agile team these wicked cool cats ARE involved in 'ensuring high value', but at the end of the day that isn't why you're calling them "QA'ers".

I've seen my share of "quality review" meetings, or fancy charts of "quality metrics", or annual budgets that talk of "quality goals" ... where in each of these cases, "quality" is talking about DEFECTS.

When was the last time someone described the benefits of TDD without mentioning, excitedly, "increased quality"? (And, yes indeed, I am certainly just as guilty as the next guy.)

So, why do I care? Why the rant?

Because, it's an indication of the generally absurdly high level of tolerance our industry has for defects.

That we describe defect density with the same word that we use to describe product "value" (to our customer/consumer) is gross.

Heck, I'd go as far as to say its a part of the reason that we have such a generally high tolerance in the first place. It's confusing and it is misleading. It's too easy to masquerade our defect problems as a "quality improvement initiative" or some other politically wimpy label.

When our customers get a bunch of "bugs in their beer" why aren't they appalled and outraged? Why aren't we? Why don't they storm out and vow to never come back? Why is it so damn okay to have defective software? For the third time, WTF?

Don't get me wrong, I'm not saying we should have an absolute "zero defect, period" attitude, that's simply unrealistic considering what we do. But we should have a low enough tolerance for defects that it makes no sense for us to use the word "quality" when talking about them.

"Quality" should be used as a measure of functional/aesthetic utility to our consumer, and not as a measure of defects. Really, it should just be assumed that defects are generally absent. This should just be implied in what it means to be a Professional.

So:

I hereby propose we as software professionals and businessmen stop using the word "quality" to mean a "measure of defects".

Well then, what word will we use? I polled Twitterverse with this question and received lots of great responses, but the group's choice as winner, courtesy of one Brian "Big Ball Of Mud" Foote, is this:
Shittiness.

Software with minimal defects has a "low degree of shittiness"; lots of defects means it has a "high degree of shittiness".

Of all the tweep responses though, overall my very favorite was from Lisa Crispin who said, "I have never liked measuring defects so it's hard to think about what to call it."

Nice, now that actually says it all. Something tells me that Lisa's company does not simply think of their testers as "the QA folk". There is hope!

TDD: The Synergy

TDD. What does this stand for?

Test Driven Development.

Said another way: Development, driven by tests.

Notice, the acronym doesn't stand for test driven design. Not test driven analysis. Not test driven coding. Nope, not even test driven testing. It is, again, test driven development.

TDD is not a "task". It's not a thing we do in addition to doing design, or in addition to writing production code, or in addition to "writing" stories. Rather, TDD it is the way we design, the way we write code, the way we define a story. It is the way we do development.

When done well, TDD exists at root of nearly everything we do in our agile team - it is the team's minute-to-minute comforting heartbeat.

TDD means that "writing a story" equates to specifying in an automated acceptance/story test (most often using FitNesse, Selenium, WaTiR, or something similar) "what it will look like" for a story to be working once we've implemented it. How the new application feature monickered on the story card must behave for it to be DONE.

TDD means that "designing" equates to specifying in an automated unit/micro test (most often using a member of the xUnit family of tools) "what it will look like" for any particular object to work once we've implemented it. In other words, what the expected behavior of that object is.

TDD means that "coding" equates to letting that unit test tell us when we've written working production code. Possibly more importantly, it means that "coding" equates to letting those passing unit tests ensure that our object continues to work (satisfy it's expected behavior) while we mercilessly refactor that object to keep it super clean and expressive.

And, in case you didn't notice in the above assertions, it means that our development is driven by tests. This means that the test is written first. The existing [failing] test is what drives us to conjure up production code. The test is the only reason for us to write a line of code. It's the only way we know what code to write - the test is our specification. Yes, we can write production code first then try to write a unit test to verify it's implementation, but, in addition to the mechanics of that likely being extremely difficult and counter-productive, that's simply not TDD.

Make no mistake about it. True TDD, at the acceptance (Story/Service) test level, is an act of analysis. And true TDD, at the micro (unit/object) test level, is an act of design. In a single statement: True TDD is much less an act of verification (as the "test" part of the name might accidentally and incorrectly imply) as it is an act of specification.

In summary, TDD provides the fundamental synergy between and foundation for all of our development "tasks" that enables us to truly build the right software and to build the software right. It ensures quality² - which, in the end, is the only true way for us to go fast and go fun.

** Upon further review, authors are changing the catchy phrase "ensures quality²" to the more appropriate phrase of "ensures high quality and low shittiness"

Rubber Duck Debugging

From an ethernal.org discussion:

"We called it the Rubber Duck method of debugging. It goes like this:

1) Beg, borrow, steal, buy, fabricate or otherwise obtain a rubber duck (bathtub variety)
2) Place rubber duck on desk and inform it you are just going to go over some code with it, if that's all right.
3) Explain to the duck what you code is supposed to do, and then go into detail and explain things line by line
4) At some point you will tell the duck what you are doing next and then realize that that is not in fact what you are actually doing. The duck will sit there serenely, happy in the knowledge that it has helped you on your way.

Works every time. Actually, if you don't have a rubber duck you could at a pinch ask a fellow programmer or engineer to sit in."

I must say, I do quite like this. I must also say, THIS IS WHY WE PAIR!

Having (hell, getting) to vet your thoughts out-loud, in real-time, with another person is a fundamental benefit of pair programming, one of the primary reasons overall productivity is increased, not decreased.

Forget asking "at a pinch", have him there all along!

Thanks for pointing me to this Buffer, fun stuff!!!

Nutshells: Why TDD?

So, ya need that techie-friendly quick-pick-list to explain to someone why your project simply cannot live another second without TDD? I know I did, so I created one. And I'd like to share it with you faithful readers.

Confidence & Productivity … Today

• Immediate feedback, ie. "cookies": Green bars that give me full confidence in what I’m coding, or in other words, meeting requirements with decreased bugs


• A more efficient design:
• Clear “expectations” (tests) drive my mind quickly and smoothly to solutions (algorithms)
• Good public interfaces – my tests make me “eat my own dog food”
• Simplicity – I’ve coded only what was needed to pass the tests

• A more effective design: in order to write software that is effectively tested in this manner, I’m naturally encouraged to ultimately write more cohesive and less coupled code

• Test “protection”: “my tests” give me freedom to refactor mercilessly to create a more expressive, readable code-base while I’m coding

• And then even more Test “protection”: “all the tests” allow the build to silently ensure that today’s collective changes across the group haven’t broken any windows

Confidence & Productivity … Tomorrow

• Fact: addressing yesterday's bugs exponentially decreases today's productivity...unless:
• yesterday 's TDD decreases (if not nearly altogether removes) yesterday's bugs


• Fact: most bugs occur upon changing an existing code-base...unless:
• Today’s [automated] tests become your safety net tomorrow
• Growing test suite allows build to be the perpetual “silent police”


• Fact: easy to understand my design; hard to understand your design...unless:
• Today’s [expectation-based] tests become your documentation tomorrow
• My expressive code is easy for you to understand tomorrow


• Fact: “code rot” (poorly factored code) slows development over time...but:
• My tests force me to keep my design well-factored – forever!


• Fact: “paper documentation” gets outdated (and lies!) over time...in contrast to:
• Automated Storytests: up-to-date, runnable “what it does” documentation (analysis)
• Automated Microtests: up-to-date, runnable “how it does it” documentation (design)

Of course, I'm not perfect, and feedback is king. So, please, pretty please with sugar on top, let me know how you think this list can be improved!

Mi Code-ah, Su Code-ah

In one sentence, what does 'Collective Code Ownership' (CoCO) mean?

In the words of Kent Beck, it means "Anyone can change anything anytime".



Said another way:  There ain't no such thing as 'My code, your code'.  Them there is bad words, mi amigo.

And then, in many more sentences...

How many times have you been routed a defect that came out of your team but you had no idea how to address it because you "didn't code that part"? How many times have you been unable to take on a story because "Jerry's the only one who knows the business logic"? How many times have you been unable to proceed until you got approval from the person who "knows that code"? How many times have you had to leave a story on the shelf because the person who "owns that code" got wolfed for a few days (or "hit by a bus")? I could ask these questions forever but I'll stop there, I expect you get the point.

Thus, as one of the main practices that stems from the value of Collaboration, Collective Code Ownership aims to break those recurring enemies of productivity. It says that, certainly within at least a team, everyone owns all the code. Furthermore, everyone is free to...scratch that, everyone is responsible to be equipped to effectively make updates to absolutely whatever code their story takes them to -- without feeling like an intruder and without having to get "permission" or any non-casual advice from your so-called "expert" or "owner". From a more measurable POV, CoCO states that everyone on the team (developer-wise) must be able to describe the design of anything the team is working on in no more than 5 minutes.

So, why possibly might this not always happen? Well, I see at least a few reasons.

• First, it requires a very high level of collaboration and trust within a team, something that, unfortunately, isn't necessarily present "We've gone Agile! Day 1".
  
• Second, it might not absolutely require it, but a test-covered, well-factored, and expressive code base goes a very, very, very, very, very long way to making this work. Ok, I lied, it is required. And again, this is something that for many new teams is simply not the situation.
  
• Third, in many cases, particularly on bigger enterprise-y projects, it simply takes a good amount of work and an investment in time (which, of course, is money) to make this happen. Alas, to much dismay, its an investment that often ends up taking a back seat to "hittin' that next deadline".

And lastly, it takes courage. It takes being comfortable with stepping out of your "comfort zones" (pun intended) every now and again. It requires shifting your self-image from "I'm good at working on this code" to "I'm good at working on code".

Heck, isn't that why you became a programmer in the first place? You didn't start your days banging on the keyboard dreaming of being "the dude who knows the billing system inside & out", or "the keeper of the logging framework", or "the Hibernate guy" did ya? You loved code, programming, creating things, bringing new stuff to life, a real Doc Frankencoder. Tap back into that, set the inner geek free, you'll be happier for it.

And, you're in luck, the benefits do not stop there.

At a team level, having a collective code ownership implies more freedom to have people pick up the most important stories or tasks, independent of what part of the app they may affect. It allows you to focus more people on the next story, to have the team bum-rush it, get it started then completed quickly before moving onto the next most important story, which in the end is a better way to run your iteration than to "multi-thread" many concurrent stories.

Does this mean that your team will religiously have everyone working on everything, everyday?  Course not, even if that did make sense, it ain't physically possible (in this dimension).  But it does mean that you should switch up pairs periodically (preferably at least daily), and share a story's tasks amongst your pairs. Have pairs face each other and be in earshot, rather than nestled off in their own cubbies and corners.  Have team design pow-wows around the whiteboard and code reviews around the projector every couple days. Use your wall-space to document decisions and debate working designs.  Collectively own the problems, collectively own the decisions, collectively own the code.

And at an organizational level, Collective Code Ownership allows your teams to grow in a way that keeps up with the way your product matures.  Many applications will start their life having intense development needs in each of its various components, and logically teams will form around these components.  This may work initially (or it may not), but it comes with a natural tendency for silos of knowledge to form around the components, which will become problematic and counter-productive as the product matures and the user's needs shift away from "component-based enhancements" and more towards "application workflows" that span multiple components.

So, yes that's right, I'm saying that Collective Code Ownership in fact goes beyond "your team"; it applies as well to "your organization".   Do the same rules apply as within the team?  "Everyone codes everything everyday", "pair with everyone", "describe the design in 5 minutes", etc?  No, it doesn't necessarily mean that.  But it does mean that you should initiate mechanisms for people to periodically get a glimpse into what other teams are working on, both functionally and technically.  It does mean that you might need to let your teams re-assemble now and again to spread knowledge and prevent yicky silos.

And finally, most importantly and most simply, whether "your team" or not, Collective Code Ownership, more than anything, is a state-of-mind:  if you need to change some code, then damn it,  its yours to change - and that's all good!

* Check out also what we IXP'ers say officially about "Collective Ownership".

Burning-Down the house

A (the?) primary essence of agile is to focus on delivering value-adding functionality as often as possible. Value-adding, that is, from the point of view of your consumer.

[Quick aside: we most often think of this in terms of value-adding 'application software', but certainly not by rule - it is whatever it is that is of value to your consumer. If you don't have a consumer, or if you aren't bringing value, then why are you spending time on it? Anyway...]

The implication of this is that many tasks we perform, while in most instances are in fact (hopefully) necessary, do not in and of themselves provide any real 'customer' value. In software terms, for example, this means that while "analysis" or "coding" or "testing" activities might in fact be necessary, they are not what our consumer/customer seeks…it is "a working feature" only that truly provides the value.

Let's bring into the discussion that holy agile grail we call a "story" (a symbol/moniker for a value-adding feature) - it is assumed that all the tasks that have to occur to deliver a story will occur, but alas, we simply should not be giving or getting any cookies for completing these tasks. We get cookies only for delivering [running, tested] features; we get cookies for delivering value.

More to the point of where I'm going with this, its not really to any benefit then to explicitly track these tasks (ie, track, meaning in your reports, "backlog" if that's a tool of yours, or things similar). Why? Well, primarily, simply because it is the story (feature) we strive to deliver, not necessarily analysis or code, etc.

(Taking a bit of a tangent here, but its an important one...) "Deliver value as often as possible". The further implication here is that we also strive to break the feature up into smaller and smaller pieces (stories); the smaller, the quicker it can be delivered, eh? And, further, the smaller the more likely to have an accurate estimate; the easier to design in an evolutionary way; the easier to test; etc. But in the end, with respect to our "stories", no matter how small we split, we do not split by tasks - each split in and of itself must still provide some sort of demonstrable value. Anyhoo...

"So Mike," you say, "where in the world are you going with all this?!?!". Great question, here it is: (MBark of this post) Do away with your "burndown charts".


The sprint "burndown" [pictured left], at least as prescribed by Scrum, is tracking tasks. Being we like not to focus on tasks, and being we only get cookies for completed stories, doesn't a burndown focus us on the wrong thing? Yes, it does. Bad burndown, bad. In addition to focusing us on the wrong things, it burdens us to worry about too many things; to, in many ways, encourage us to micro-manage (which, of course, is not good for anybody and very un-agile). If you need more, how about the fact that it can lead quite readily to false-negatives with respect to how "done" you really are: "great, Bob, you've got task x, y, and z's hours all used up, sweet!"...but, uh, what the heck does that really mean with respect to the status of obtaining your real goal (delivering the feature)?



Thus, a "burnup" [pictured right]. A burnup tracks only features (whatever that might mean in your context); the features represented by stories, each assigned a point value to indicate size. When a story is complete (a feature is "done"), the burn goes "up" by that feature's points. No hours, no tasks, no minutiae about various random "inputs" - rather, just a simple representation of what we really care about - features being output. Easy-peasy, and way more in line with our goals. And, of course, as far as contributing as a tool to help us determine our velocity: if we really need to measure anything, what we really want to be measuring is our rate of delivering working software, not our rate of "doing analysis", right?

Be not mistaken by my message, it's not to say you and your team won't have daily knowledge of what particular tasks might be going on, I sure as hooha hope you do! It's just that we don't go so far as to officially track or measure them. That's what your daily stand-up is for. And, of course, common sense is required, if you really want them to be visible, fantastic (I mean it) - go ahead and hang up some task stickies on your Storyboard or some other "information radiator" hanging in your team room.

But, alas, my spidey-sense says: unless you're hoping to burn down your project, steer clear of the Burndown chart.

Riddle Me This, Mr Pair Programmer

"So, my programmers were pairing; one was on the middle-tier stuff, the other on the UI layer. Things didn't seem too efficient to us. What's up?"
Two people working on different "pieces" of the same story, even if simultaneously, is not "pair programming" - this is plain old fashioned delegation. In fact, this often decreases overall productivity, due to the fact (one of many) that putting the pieces together often exposes mismatching interfaces requiring varying degrees of rework.

"Pair programming" means two people working together, side by side, on the same exact piece of code - two people thinking and talking together, one person [happens to be] typing. Furthermore, 'one person typing, one person watching' is also not "pair programming"; the key to pairing is two people thinking as one...two people collaborating.

"How to best go about selection of pairs?
Pairs should typically not be assigned, they should be formed naturally on their own. [But, see the next question for more info]

"I suspect that some pairs, for example two junior programmers, might be less effective and thus decrease productivity and code quality. Is this true?"
Yes, technically there is some truth to this... at least at the beginning. Part of the point of pairing is to help share skills and knowledge, so it may help to match up more skilled with less skilled.

BUT, much more true when you start pairing as a team, not so much once you've been at it for a little while. Once everyone is of relatively equal understanding (of the practices at least) everyone should pair with everyone. The only requirement is that the two people get along from a personal POV (and if they don't, maybe they shouldn't be on the same team anyway?). Within reason, the more "movement" the better. @see Promiscuous Pairing.

Also, something else to chew on. Having "preset/preference" pairs actually works a bit against the desired outcome - the essence of PP is having "two heads" working on one problem, in sort of a checks & balances way; the longer 2 people work together, the more they become "one head", which in large part works against the goal ("two heads collaborating").

"Do we need a certain minimum level of skill across the team before taking on pair programming?"
Absolutely not. Getting to a shared higher "level of skill across the team" is an outcome of PP (not a prereq).

"Is there a way to verify the quality of a pair that is not that experienced?"
The team should simply pay attention and use common sense.

"Is PP appropriate for some tasks and not others? Aren't small complexity activities not worth pairing on, since it just delays them?"
No.

First, on a slight tangent, part of our goal as craftsman in general is to make all tasks "small complexity", ie. simple - small stories and evolutionary design exist in large part to virtually eliminate "large complexity" altogether. When everything feels like a "toy example", then we've succeeded.

Anyway, the "stupid typos"/"silly decisions"/"shortcuts"/etc are actually more likely to occur for the "simple tasks" becuase the programmer often sees it as just that: "oh, this is just a simple little thing, I don't really need to TDD/[fill in the blank], what could go wrong"...and wallah, we've got a broken window.

Now, all that said, yes, if the task is truly a few minute trivial thing, then it may not help to PP. As with all things, common sense is required.

The truth is that the time where one in fact might be better off working alone is when they have a real doozy of a problem that they need to concentrate very hard on to get their head around. If you need some quiet dorm room time, go ahead and split up for a stint. Prototype, spike, get your head about you, then regroup and get to it. Rule is though: "No non-throwaway code during solo time".

"Should teams adjust their expected velocity to account for the effect of pair programming, especially when first adopting?"
My experience is that velocity rarely decreases enough to try to predict it - assuming they pair effectively (which is not hard), the benefits are often gained immediately.

"Do we need to pair from the onset of a story?"
Yes.

"In other words, can a story be begun by one person, then a pair picked up halfway through?"
Not advised.

Pairing actually tends to be a bit counterproductive if "picked up halfway through", mostly because the "pair" comes on and is quite likely to become, at best, a bystander observing what the other has done / is doing, or, at worst, just "a pain who won't stop poking holes in my design".

Again, true pair programming means the two are largely thinking as one, just so happens only one person is typing.

If pairing is attempted "half way in", the result is often "one person thinking, another person simply watching" - which, consequently, is more of a waste of time than a benefit.

Where'd Jeff Probst go? (aka, Kicking someone off the island)

Yesterday I spent the better part of my morning reading through the 130 or so messages in the Scrum Dev Yahoo group's "Rotten Apple In Scrum Team" discussion, then I posted this "newsy" summary of the discussion on InfoQ.

In a nutshell, Marko told the group of a guy on his team he sees as a drastic "under-performer", or as he put it originally a "rotten apple", and asked for advice as to what to do with him. Read the InfoQ post to get a deeper sense for how people responded, but the gist of most of the advice was for Marko to take an open-minded and objective stab at finding out (and/or helping the team find out) what's really driving this person's performance, or, rather, lack thereof. And then to help him out.

"Try 'Beginners Mind'"..."take queue from Linda Rising"..."pair up with the guy"..."be nice, be helpful, be supportive"...and so on and so on. Hear this clearly (before I get to my real point of this post): I generally agree wholeheartedly with all the advice presented.

Now though, all that Dr. Jeckyll buildup for the Mr. Hyde thought: 130+ replies and not one mention of "kicking someone off the island"?

[...and the crowd gasps in horror...]

I've seen, and I'm sure you have too, a team who had an individual who truly did bring the team down. Typically not because they couldn't program quite as fast, or weren't quite as smart, or weren't quite as good in front of customers, or anything skill/experience/productivity-related like that. Rather, simply because they had a negative attitude, because they didn't play nicely or just plain didn't care.

[*Note: For what's worth, I do not think this applies to Marko's guy, but the discussion got me thinking anyway.]

One seriously under appreciated technique that I stress should be considered for these true "rotten apples" is to get them off your team, kick 'em off the damn island. No one says you have to fire them, just get them out of the way somehow.

Forget tools, intelligence, certifications, experience for a moment. The degree with which having a good team (in the "synergy" sense that is) contributes to good results (and, hell, a good time) is amazing; having a great team, well that's just indescribably astounding, magical even. Conversely, the degree with which having a bad team atmosphere can lead to serious bed-shatting, well, that's also quite amazing as well.

So if you've got someone who after the Prime Directive and the Beginner's Mind and the Pairing has still got that sour-puss face and, more importantly, is still killing your team's ju-ju, then by all means call the spade a spade, cut your losses, and remove them. Be as graceful as you like, but please, as Bo used to say, just do it.

Again I stress, I'm about as "glass half full" as they come - I'm not trying to encourage a general exclusive, head-chopping, "only the best" attitude. 95 times out of 100 your man intends the best and just needs a little love, and by all means you outta be doing your damnedest to facilitate that happening. My point is that for those other 5, stop being so P.C. and get the bad apple out of your basket. Your team's ju-ju will thank you for it.

** Update: Thanks to Esther Derby for shouting out about her related and more concretely useful post from some time ago echoing the same sentiment.

Why do pears fall in love?

So, I've been following Corey Haines' Pair Programming Tour. Check it out, it's a rather cool gig, both as it brings the topic of Pairing back under a much needed limelight, as well as, in and of itself, the totally unique and inspiring act of Corey taking such a tour in the name of our craft. Kudos Corey!

It's got me re-inspired to write up some of the things I've always wanted to about pairing, as I'll do now and then here in my nifty new super fantastic blog.

To start, I'm drumming something up from one of my first writings years ago about this wonderful thing we call Pair Programming. It's a simple list, intended to highlight the major reasons why we pair. Here it is...

When programming (ie. designing) alone even the most disciplined/skilled of us will:

• Get stuck on various "how to's" (often for a great deal of time)
• Often stray, both in thought and code, away from the current task at hand
• Spend a lot of time debating various decisions in our head
• Create designs only we understand, thus requiring a future time-consuming learning curve for everyone else (trust me)
• Be prone to, at least occasionally, make bad decisions - each of which incurring technical debt*
• Be prone to make programming errors (especially if we're not test-driving), thus incurring technical debt*
• Be likely to "cheat" (out of good programming practices), thus incurring technical debt*
• Periodically get burnt out, requiring a break [during which time no work is done]
• Have no one to encourage us or celebrate with

* "technical debt" = exponentially costly [ie, time-consuming] future rework!
See also: Martin Fowler on Technical Debt

When pair programming (ie. designing) even the least disciplined/skilled of us will:


• Rarely get stuck on any "how to's" - for those things that stick us, our pair is highly unlikely to be stuck as well
• Remain focused on the task at hand
• Be able to more efficiently [quickly] make design decisions collaboratively with our partner
• Be sure that at least one person won't have a time consuming learning curve to understand my design
• Be forced to verbally justify the rational for our decisions, thus greatly decreasing the likelihood that we "miss something"
• Rarely make a programming error that our pair won't pick up
  
• Not be able to "cheat"
• Be able to pass the keyboard to our pair when we need a break - keeps us moving, and keeps us fresh
• Have someone to constantly encourage us and celebrate with (ie..fun)

For these reasons, it has been shown that diligent pair programming, at least over any non-trivial period of time, does not decrease team velocity. In fact, it will often increase team velocity (and, as a nifty side effect, software quality as well).

So, chew on that, maybe it'll help you in the next hallway conversation where you need to explain to someone how "pairing does NOT double the time it takes to get something done".

And of course, remember why this is necessary in the first place: The world we live in these days, well kids, It Ain't Your Daddy's Software Development...

**Update: Check out this for some Q&A about Pairing