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!

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!!!

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".

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.

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