Finetix Breakfast in NY

Finetix is hosting a breakfast in New York for those of you who may be interested in the application of Agile in Capital Markets. Ken Schwaber will be talking about SCRUM and I'll be presenting on XP in Capital Markets. There will also be some brief case study's from David Lattimore-Gay's experiences.

My First Real Pairing Experience

This recent blogging of "how to do good pairing" caused my first real pairing buddy to remind me about how different we were but how well it worked.

Back in the mists of 1992, I was a Smalltalk developer at Morgan Stanley where I got to work with Lynn Riehl. She was a more senior IT person than I and understood the business, I was a young techy geek who could make Smalltalk dance. Every morning for two months, I'd turn up at her desk and we would commence to develop the system sitting side-by-side in front of the machine. I think all the good pairing behaviour was there:

• neither of us ever used our "authority" to push a point, we would discuss things and try to find agreement
• we would talk as we did things to externalise what was going on - Lynn could hear how I was thinking about the business, I could hear how she was thinking about this new object-oriented stuff
  
• We didn't have huge design documents or a framework in mind, we would implement specific features one at a time all the way through
• the On-Site customer was the FX desk on the same floor. Lynn had great relationships with all of the traders and the head of the desk. Lynn would do regular demos for them and generate feedback and prioritised to-do lists
• we would agree on an approach and stick to it until one of us would say, "hold on..."
• both of our language patterns became, "I think/I feel...." rather than "generally..", "the right way...", or other such terms (actually I think this was Lynn's natural speaking pattern which I learnt to adopt)
• we had periods of intense work with frequent breaks for ice-cream
  

I think a lot of this behaviour emerged because we were under a tight deadline (probably unreasonable deadline), neither of us had all the information or ability to make things happen, it wasn't entirely clear what the business needed or wanted but we were both determined to make things work (stubborn is the word that comes to mind).

I don't even remember how we started to get into this behavior model? I think it was probably something along the lines of Lynn getting me to show her how to write a piece of Smalltalk to do X using the frameworks Morgan Stanley had at that time. Then she tried to modify it and had some questions so I'd come back, and pretty rapidly it was just easier and more effective to sit there all the time.

We did get complaints about the noise of us pairing from one of the other developers - which is of course one of my measures of good pairing!

We did do some unusual behavior though which I'm not sure is appropriate for pairing but is worth mentioning:

• Lynn would stay later than I did and be in earlier, and would go through and review what we'd done and clean a lot of it up. Sort of refactoring and tidying things up so it was ready for us to have a clean start in the morning when I finally turned up (there was an interesting incident where I got shouted at across the Morgan Stanley staff dining room, but thats another story....). Not exactly a fair balance of work
• Also Lynn would deploy the latest version every night so the users always had the latest and greatest (the single person responsibility for deployment is the unusual behavior, no the regular delivery) [Lynn's memory is we didn't do it every day - maybe I just thought we did!]
  
• although there were other resources we tended to stick together as a pair. I think Lynn did work with Bernard Horan occasionally, but I've never really asked them about if this was a pair experience or just two people working together
• I discovered only recently that occasionally when I thought we were both thinking hard about how to solve a tricky technical problem Lynn was actually trying to decide what she was going to do at the weekend! Now interestingly this did not effect our good pairing experience - so I can assure you that ignorance can be a good thing. But it does make me realize I can could be duped if I wanted to be duped (or is that "can be duped"?)

Clearly, I had the easy time of it not having to deploy or do the clean-up.

But was it ultimately effective and valuable ? I believe it was, but the following facts stand:

• we delivered the system incrementally, delivering every day. Bugs could be fixed within minutes, features rolled out as they became available
  
• Lynn rolled it out to 2 currency traders as a trial, and discovered the next day that the other traders had started using it without telling us! Not only that it was working fine for them and they were very happy
• 2 people of very different skill sets, who didn't really know each other managed to figure out and deliver what the FX desk needed within the bounds of an impossible deadline
• I learnt about the FX business inside and out - and it still stands me in good stead today
• Lynn became a pretty decent Smalltalk programmer - but she jokes that working with me on that project taught her that she wasn't really geek enough to be a serious hands-on developer, and her talents lay in project management
  

Lynn and I are still great friends 13 years later - so contrary to the fear about falling out that my colleague raised, I think you should be more afraid of the number of close friends you'll end up with after pairing with them.

Pair Programming: Issue 4 : You're in my way!

[The fourth installment of my response to a colleague's queries about Pair Programming]

Issue 4: The more senior coder can often feel impatience with the other coder, resulting in a loss of respect that the senior person might feel for the junior one

Similar response to my previous blog entry: you're not really Pairing. The most senior person can learn something from a junior, even if it is only patience. I would go as far to say that in such circumstances this "senior" person is actually an intermediate who has not yet learned the behaviours that define a senior developer (to me anyhow). These include patience, welcoming questions and admitting when you don't know.

Often mistakes are made in rushing to implement "the obvious" or "the cleverest" solutions and it is a mistake to confuse speed of development with effective development. Efficiency of code generation does not equal effective development. Having juniors who require a slower pace due to either their questioning or their need to understand the "obvious" is an advantage. This challenge to the intermediate developers helter-skelter, I-know-what-I'm-doing approach and is often the main value of Agile!!

Think of it this way: if all us senior development guys and gals are so good and know what we're doing why was it necessary for Agile to come into existence? What is the point of the discipline? Is it maybe because the development processes we grew up doing (the non-agile ones) were failing? Maybe we have bad habits that need to be trained out of? By having the juniors around we (a) can show them the better way we know is better (but might not practice yet), but maybe more importantly (b) they can keep us true to our intentions of Agility by questioning us and pacing us.

It's a way around the hypocritical "Do as I say, not as I do" maxim. Its more, "Do as I say, and help me do as I say".

Sometimes juniors get criticized for asking "stupid questions". There is no such thing as a stupid question: just ones you do and do not know the answer to. Often the frustration intermediate developers have in this context is having to explain something they've taken for granted. This comes back to the fear/embarrassment point again. Sadly many intermediate developers who think they're senior haven't yet learnt a valuable lesson: admit when you don't know something and do something about it. People will respect you for this behaviour.

Pair Programming: Issue 3 : I like you so much I won't Pair with you

[The third installment of my response to a colleague's queries about Pair Programming]

Issue 3: The ill feelings that develop during PP exercises can ruin a team dynamic. Good friends who do PP can often end up as not-so-good friends

Nonsense. I have only ever seen Pairing improve the team dynamics - the issue here I think may be different: Two people sitting at the same desk is not necessarily Pair Programming.

As per my previous post the practice of Pairing is not doer-criticiser. It is a real collaboration. You can hear a real Pairing experience. However, I have seen poor Pairing leading to falling out.

People who attempt Pairing without starting with someone who's really done it before, or who do not commit to it as a different way of behaving will not gain the benefits. Like any practice you have to really do it: externalize your dialogue, concentrate on the system not the mechanism of its construction, seek to agree, state who you feel and think using "I" and don't speak for others (e.g. "this is not the right way","generally...","the rest of the team...")

Pairing is a different behaviour model to normal working patterns of two people. The "norm" in projects is either person-with-problem-and-helper or senior-guiding-junior. Hence why a lot of questions of fear-about-criticism and seniority come up in talking about Pairing. They are generally the only models people have experienced.

So who is responsible for ensuring good Pairing? Everyone! The Coach, the Manager, other Pairs, the Customer....everyone. If you hear a Pair not working you must say something. If Pairing is broken, then Agile is broken IMHO.

Pairing is different. In my experience the interactions help build teams as everyone starts to appreciate the way others work and the personal benefits of Pairing. It is challenging but it pays off.

Pair Programming: Issue 2 : Stop looking at me!

[The second installment of my response to a colleague's queries about Pair Programming]

Issue 2: Many coders are nervous when someone is watching them code over their shoulder. People get embarrassed when they code something that the compiler will catch as a syntax error. People can't concentrate to their fullest.

Nervous, embarrassed, can't concentrate - these are all outcomes of the most basic of things: fear. And the fear in pair programming is exposure to another person's judgment about your performance. "What are they going to think of me?" , "Will they discover I don't know what I'm doing?" , "If I get something simple wrong they'll think I'm an idiot", blah, blah. But this is based on a model of pairing which is false, and usually held by those who have not really experienced true Pairing.

This fear comes from a model where you are programming and your partner is watching and critiquing you. In this interaction the only sounds are the tapping of the keyboard and the occasional, "that's not right", from the critic. In good pairing there are the additional sounds of commentary from the coder and uh-huh-ing from the partner. Think of it like the internal dialogue that often goes on inside your own head when you're doing something, except you're externalising it and the "other voice" really is someone else.

I go back to this "my-our" difference in the Agile attitude: its not my development of X but our development of X. Its not about you, its about us creating a system.

In good pairing the concentration is on the screen on not on the performance of the individual who happens to be in control of the keyboard. In fact because of the nature of the externalization of the dialogue there is often a merging of the way a pair approaches developing code. There is a discussion about the system not about how an individual is doing things.

In my experience the externalization of your inner dialogue coupled with concentration on the instantaneous state of the system as the subject of discussion produces a much higher level and intensity of concentration. Especially if you are practicing Test Driven and Refactoring. In fact, this is one of the reasons the 40-hour week practice exists as the intellectual burn on a pairing situation is so much higher.

Pair Programming: Issue 1: Space Violation!

A colleague of mine suggested I blog something on why I am an advocate of Pair Programming (PP) - he is somewhat of a skeptic. He mentioned some unfortunate incident with an insect and an orifice.

I'm going to try and avoid reiterating the papers or data you can find on the web like http://www.pairprogramming.com/ or any of the wiki sites. Rather I'm going to make a statement, and address four concerns he raised in four separate blogs over the next few days.

Statement: I have seen Pair Programming work over and over in many circumstances and that is why I believe in it. To me it is the primary mechanism upon which successful Agile depends. It is the only execution practice which is first and foremost about people and their interactions, all the rest are technical (Stand-Ups are an organization practice to me)


Issue 1: People generally do not like to have their personal space violated, whether it be their physical space or intellectual space.
I find this a worrying view point, but not an unusual one. Many developers consider themselves to be owners of a physical or intellectual place that they need to defend against violation.

One of the big shifts in adopting an Agile stance is the attitude change from "my" to "our". Traditional: My code, my space, my goals, my tasks. Agile: Our code, our space, our goals, our tasks. And not just in words, but in actions. Pair Programming is the practice that helps most with this my-to-our change. I suppose initially it is the very violation of the "my" attitude that PP demands that causes the change in itself.

I advocate teams setting a side a set of shared machines and space to start pairing. In this way you can get around the "my" space issue and the space becomes "our" place to develop. Equally the machine used for development should be a consistent development environment that is not personalized to an individual. If you stick to discipline of PP with pairs regularly swapping partners and machines a lot of the "my way" behaviour fades away (coding styles, dev environment set up, my IMs, my email, etc).

Still having some personal space is important! 10 years ago the "cave and common" architecture was a hot topic, and I believe this is appropriate for Agile teams. This "special space" is often criticized as needing more space. However, it is possible to fit into the same space by halving the personal desk area and using the space for pairing stations.

So what about the "intellectual space" violation? Well being extreme about it, I believe it is irresponsible and unprofessional for a developer to defend an intellectual corner and expose the client to the attendant risks. I often describe the problem as "getting run over by a bus" - in the traditional defensive model a project can fail if one developer gets run over by a bus. In a Pairing project feasibly all but one of the developers could die in a bus crash and the project could still continue. Fatuous? It does happen: I was told only the other day of a real incident of a "key" developer dying during a project and it causing terrible consequences (beyond the obvious trauma).

There is a fear associated with PP about exposing your knowledge and losing control of your position through sharing. I have never seen this happen. If anything it can help strengthen your place as exposing your skills helps others appreciate them more. Further, by needing to explain your thoughts I find it deepens your understanding and cuts through the fluffiness of thought to get things over to your partner. Also, pairing is a two way street: think of it as an opportunity to gain new skills !

One way of looking at the traditional reaction to own part of the system or own part of the project intellect is that it is a way for developers to try and demonstrate their personal worth to the project and team. I saw the detriment that long-term PP had at Connextra where the value of the individual faded into the background of "the collective". Consequently we created the Gold Cards practice as way for individuals to have time to show their individual prowess. Just as there needs to be personal physical space, there needs to be personal project task space.

On a slightly different note: PP is the way in which collaborative behavior becomes visible to stakeholders. How else do you show that collaboration is really happening?

I find it curious that everyone is bothered by Pair Programming but rarely picks on Shared Code Ownership -with respect to the my/our change. I wonder if this is because they interpret Shared Code Ownership as "access to your code so I can change it" rather than it being "our code"?

What does you Recruitment Process say about you?

Having recently moved jobs, I have been generally unimpressed with the recruitment processes I have encountered. My particular bug-bear is the "technical assessment" questions and my second favorite "the personality profile".

From an eXtreme point of view I fully support the "test first" approach but as ever you must be careful what you are testing for. A lot of the technical tests take a long time and are extremely detailed and demand deep knowledge of the syntax and foibles of particular systems. But is that what you want to know about a candidate? Especially if they are going to be working as a consultant ? This is testing knowledge not application, and it is application which counts. I suppose an analogy is technical tests are like coverage tests, not functional tests: and to the eXtreme mind functional rule!

The "personality profile" supposedly addresses these short comings but again I fear they are testing the wrong thing. These are analogous to architectural reviews of a system -they inform you about the general shape of things, how you believe things hang together and you decide whether you believe its fit-for-purpose. But at no time is there any kind of measure (and I use that accurately, i.e. not a metric) of fit-for-purpose.

So what do I believe is the right way of doing this interview process? What do I see as the recruitment equivalent of functional testing?

Well as a test I might write it as, "I want a candidate who can understand a users needs, use development tools, discuss implementations, do test first, etc. so that they can deliver working systems in the context of our usual working environment".

And how do you implement this test? Pair Programming.

We used this technique very effectively for years at Connextra. The interview process goes like this:

• Sift through CVs for reasonable candidates (I should blog on how to advertise too...)
• Brief telephone interview to test whether they are genuine and have the basic skills necessary for the role. This could include a basic technical and syntax test, but should be brief and take no more than 10 minutes and able to be asked by anyone (i.e. not necessarily requiring technical knowledge)
• If they pass that (and its amazing how many don't) invite them in for a Pair Programming session of about 30-60 minutes. If they freak and say no then you probably didn't really want them anyhow (never had this happen BTW)
  
• If they pass the Pair Programming, then get into the company fit and position discussions, which is probably only 2 or 3 more phone calls or interviews
  

So how do they pass the functional test of Pair Programming? Well its definitely an instinct thing, but in the eXtreme tradition the Pairing process will expose a little of everything all the way down. You will within 10 minutes figure out if the candidate knows the technology, knows how to program, knows how to interact with other stakeholders in the system, and whether they have what it takes to work in your business and deliver value.

I recommend the 30-60 minute timing so you can get 2 people to do 30 minutes each with a candidate. The second one tries to understand what happened in the first 30 minutes through the candidate reiterating and demonstrating. This also helps avoid the single chooser problem.

There is an anxiety about Pair Programming in the interview process about it being a waste of resource. I would argue that it is in fact a valuable investment for two reasons. Firstly, it is the only truly effective way of testing if a candidate is entirely suitable for what you wish them to do. By testing the right thing early it reduces the costs of fixing mistakes later - which might include your company's reputation! Secondly, it involves your current employees directly in helping to choose their future colleagues - which can in itself be a motivational exercise.

Also, remember the interviews are a two-way street, and your company will be judged on the process of interview. In fact it is the only true measure a candidate gets of you. Think: What does your recruitment process say to the candidates?

Blogging Virgin

So this is the traditional, "I've never blogged before" first entry. Being an eXtreme Programming type, I of course Wiki but have never blogged. I have recently joined Finetix where blogging is encouraged, so I have been encouraged so....