Pair Programming doesn't work without TDD?



About a week after I wrote a pairing blog post, a work colleague from another team invited me as a guest to heir teams meeting to discuss pairing. He hadn't read my post but had heard about the multiple keyboard thing and thought I might be interested.

The team I sat Phoenix, are a hybrid between my company and ThoughtWorks, who we've got in helping us.

ThoughtWorks have a wealth of experience with XP practices so naturally we're trying to learn all we can.

What does it feel like when pairings going really well

People said they felt like they'd learned something. Others added they also liked when they felt they'd taught something.

What kept happening though was a divergence into talking about TDD, people really seemed to enjoy and find value in the art of testing.

I saw my characterisations come somewhat to life and some of the team described that for two talkative people they could waste time discussing the best way to solve a particular problem or how to write a test for it.

Does this mean, that to pair program ideally you should be doing TDD? It was almost implied or is it because we're relatively new to TDD. I could conclude prehaps prematurely that to feel like you're doing pair programming really well you have to do TDD.

Pair Rotation

When it came to pair rotation, they rotated daily, which I considered the better way forward, but they were finding it hard to context switch on such a regular basis and felt it slowed the process down.

This is an interesting dilemma, people probably have different perceptions of why rotating is important, the company probably is interested is the so-called buss-ability factor. Whereby if someone tragically is injured by a bus, then work can continue because enough other people have shared knowledge about the work that they can continue. My team tend to rotate the pairs after each story and we were going to try rotating at the end of each day. Now I'm not so sure.

In favour of frequent rotation is more people see the code, more ideas and discussion arrise and hopefully a better solution emerges, or prehaps people just sit there try to focus on the new problem whilst daydreaming about the one they've just come from.

Shared accounts

We don't as of yet have pairing user accounts, apparently there's security issues around this. Though as was pointed out; sharing passwords is an inherently less secure option.

I'm thinking shared accounts are a great idea and one key part of these accounts for me is that they don't have outlook.

Have you ever noticed if you turn off outlook or email, you can get more done. Yes I'm pointing out the obvious. I'm trying to urge the team into a no interruption window. Phoenix already do.

I'm hoping a clear 2 - 3 hour window in the morning after the daily standup will enable us to get all the important things done in the morning.

Desk Arrangement

Desks always seem an issue, I've talked about this in my post about the Team Room, people were huddled in the corner of a L-shaped desk, which isn't really ideal, but getting all new desks is an expensive proposition. I think they're going to try moving the machines into a better position but there's only so much you can do. Our desk arrangement isn't really that far off Martin Fowler's UPOD arrangement the desks not being straight seems to be the main problem.

I suggested the multiple keyboards technique as it gives you a little more space to breathe. Someone mentioned Pairing Gum might be necessary for some people, which is alway a nice consideration :)

The Team Room



I've just been reading this article about team rooms on Martin Fowlers blog. Is it strange that developers spend so much time obsessing over our work environment? Or is it inevitible as we try to optimise every part of the development process.

It seems especially valid, as we have Thought Works in working with us at Totaljobs and they have the central desk, whereas we have more of a UPod but with corner desks. As he says pairing is a bit fiddly but quite possible.

Our wall is covered with inpirational posters and drawings of how things should look. Done in original felt-pen. Though reading this article I think there's a strong need for some plants in our area. A bit of forna is always a calming influence I find.

I'm thinking a fruit bowl as opposed to the donuts and cookies might be a good idea.

Martin's article mentions a minimum of 2 20" monitors. We only have 19" and in some cases 17". We managed to get updated PC's recently with more memory and cores etc. Which is great... but how could they forget monitors. I'm going to have to put forward a business case as to why larger monitors will increase productivity.

If anyone has any idea of what to put in the business case please let me know.

 

I've been after 2 24" Dell Ultrasharp monitors now for several years, but at over £460 a piece, they're out of my budget and no-one seems to be able to tell me if they'll work with a MacBook Pro 13". Plus my wife reminds me how 1 of them could pay for a holiday let-alone 2. She has a very valid point, maybe if I built something at home that actually made some small amount of revenue I could justify it.

Why do we care so much about our equipment. If I were an electrician I'm sure I'd have the best kit money could buy, but as developers I think we so often accept less than the best.

Bigger monitors reduce the amount of time spent re-arranging windows so I can get a better view of what I'm working on. I'm seriously thinking that going forward 3 monitors is a necesessity. When you've got Visual Studio, SQL Management Studio and a browser open you're out of space.

Drawing Pads

I find to aid the development process we use a lot of scraps of paper, the back of printed backlogs and just about anything else. But it seems nothing compares to a quick doodle on a scrap of paper to get an idea across. Maybe if we had a board available we'd use that, but a scrap book is a viable poor-mans alternative.

 


Search

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2014