Experience Report: Pair Programming Interviews

Ivan Moore wrote an article a while back on how he runs pair programming interviews. After introducing them to the recruitment process at my company I have to agree with Ivan that they’re incredibly valuable – among other things they’re a great way for a potential employee to show they have a developer conscience. I wanted to share some of our learnings too.

Real Code

We use real code and real problems we’ve already had to solve. I know others like to use programming exercises, but we like to see how candidates deal with problems which are more relevant to the job they’re applying for such as dealing with legacy code and unit testing.

Code Review

We start by walking the candidate through the code and it’s context, give them 10 minutes to review the code by themselves and then discuss their thoughts. Outside of the actual pairing exercise this is a great opportunity for them to show us how well they understand OO principles and practices by identifying any code smells. We’re also looking out for how well they explain their answers as an ability to communicate well is essential.

The Exercise

Next we roll up our sleeves and start programming. We set the candidate a challenge (in the same code base), work with them as much as possible without making it too easy, explain anything they’re unclear of and help them with any tools they’re not familiar with. Whenever we come to a tricky or challenging situation we ask them what options we have. If they’re totally stuck we will suggest possible solutions, but ultimately they’re the one making the decisions. The exercise continues until the allotted time runs out (1 hour normally).

It’s about what you do not how you do it

We explain to the candidate at the beginning of the interview that there is no finishing line. What we’re looking for most is how they approach a problem and how well they work with others. Often people who get the furthest do so by making risky refactorings and poor design decisions.

Pair pair programming

It’s always good to have more than one opinion so generally there will be two people in the interview aside from the candidate. One takes part in the exercise whilst the other acts as an observer. This allows the navigator to focus on the exercise. After the interview we get together and discuss our thoughts. Often one of us will have forgotten or not noticed something from the interview and this ensures we get the most balanced and fair view possible.

Does it work?

So far everyone who we’ve recruited who has taken part in the pairing exercise has lived up to, if not excelled our expectations of them based on how they performed. One drawback is although we do try to keep the interview as relaxed as possible it can be quite intimidating for some, however having done quite a few now I cannot imagine recruiting a developer without using this technique as part of the interview process.

Group for people interested in changing the face of UK Govt. IT

At SPA2010 last week Matt Wynne organised a BoF session around how we can change the way the UK government delivers software. We had a really constructive discussion and lots of actions came out of it, one of them being to set up a group for people who are interested in getting involved to effectively communicate and bring together our collective knowledge and abilities, create a bit of a movement.

If you are interested in actively getting involved (rather than just commenting from the sidelines) please sign up:

http://groups.google.com/group/uk-soft-pract-esd

In a few days I will publish the actions we identified from the discussion and we will be looking for people eager to take on some of the tasks.


P.S. Don’t worry about the name if you don’t like it. It is likely to change and not the most important thing to be discussing at these early stages.

Thoughts on TDD as if you meant it

I’ve now been to Keith Braithwaite’s TDD as if you meant it session twice and also ran a series of coding katas in this style at work using Conway’s Game of Life.

Here’s the concept:

1) write exactly ONE failing test
2) make the test from (1) pass by first writing implementation code IN THE TEST
3) create a new implementation method/function by:
3.1) doing extract method on implementation code created as per (2), or
3.2) moving implementation code as per (2) into an existing implementation method
4) only ever create new methods IN THE TEST CLASS
5) only ever create implementation classes to provide a destination for extracting a method created as per (4).
6) populate implementation classes by doing move method from a test class into them
7) refactor as required
8 ) go to (1)

What I’ve learnt

  • It’s really hard to get going.
  • At first it feels ridiculous and pointless effectively testing things like true == false and having the code under test actually in the fixture.
  • A recurring theme has been throwing away lots of code. Focusing on trying to do the simplest possible thing often means your understanding and your solution frequently changes and continuously becomes redundant. It’s a very frustrating experience.
  • I don’t think it’s at all a practical way to write production code.

If I’m not going to use it what’s the point?

As Keith has repeatedly stated, he would not recommend you went back to your job and started coding this way. What it is though is an excellent training exercise, the equivalent of a musician practicing scales. It emphasises the core principles of TDD more than anything else I’ve tried or read.

Therefore I’d highly recommend it as something to do on a relatively regular basis to help refresh your TDD muscle memory and it’s a great way to introduce the concepts of TDD to the uninitiated.

As Queen Elizabeth II once said, “It’s all to do with the training: you can do a lot if you’re properly trained.”

Government IT process review update

The election may have put the breaks on the petition, but significant progress has been made on other fronts. In parallel to the petition I set up to demand the government review it’s outdated IT practices, Robert Chatley (with the help of a few others) wrote a letter* to the National Audit Office asking them to update their guidance and recommendations for systems development. After a couple of prods they agreed to a meeting and last week Robert Chatley and I went to see them.

To cut a long story short (I’m supposed to be packing for my hols so have to be brief) it was a very positive meeting. We met with their Director of IT and Systems Analysis, Sally Howes and her colleague Leena Mathews. Both, but especially Sally were very receptive to what we had to say. Fortuitously they are in the embryonic stages of a wide reaching review of government IT practices so this looks like a fantastic opportunity to make a real difference.

One thing they’re particularly keen on hearing about is large organisations who are using and succeeding with agile practices and specifically senior people within those organisations who they could talk to. If you know of or are working for such an organisation please email me at email with the details of people who may be appropriate for them to talk to.



*You can read a draft of the original letter to the NAO here

A response from Stephen O’Brien, Shadow Health Minister

Dear Mr Bowley,

Thank you for your email regarding the NPfIT. I certainly agree with your point that drawing up contracts for IT systems that have yet to be developed has proved costly for the taxpayer and for Government. Nowhere is this more true than the National Programme for IT where only one hospital has received a full implementation of Lorenzo due to the fact that it had not yet been designed when the Department of Health let the contract with CSC, and only 12 hospitals have received Cerner Millennium – a U.S. system that has had to be adapted extensively for application in NHS Trusts by BT.

Whilst I have not come across the Agile approach before, I will certainly bear it in mind as we seek to develop our policy of giving local NHS Trusts a choice of IT system through a central catalogue of open standards/accredited systems. I will keep on record any further information you are able to provide in writing about the Agile methodology and would welcome any such information in response to this email. Once again, thank you for getting in touch.

Yours sincerely,

Stephen O’Brien

Shadow Health Minister

Government IT process review petition update

The Number 10 petitions website says they’ll usually forward on a petition to the relevant department once it has 500 signatories. We’re currently 176 signatures short of that total so if you haven’t already bothered everyone you know to sign it please do.

If you need some encouragement I read on only Monday that the government is yet still trying to commit to another load of juicy big fat contracts for the NHS IT scheme (NPfIT). It was reported on BBC News here. This revelation came from an excellent Radio 4 documentary the previous night about the government’s IT failures which you can still listen to on the BBC iPlayer. Here are some soundbites:

  • £622 million pounds was wasted on the Rural Payments Scheme project according to Edward Leigh, head of the Commons Public Accounts committee. Some farmers actually committed suicide because they didn’t get the money they needed and Mr Leigh calculated it would have been more effective to have written a cheque for £20-30,000 to each and every farmer in the country rather than have built the IT system in the first place.
  • 100 Accenture “experts” were employed on the Rural Payments Scheme at an average salary of £200,000 (! – at that kind of money I think I’m about ready to sell my soul and go work with Tiger).
  • 9 fire brigade control centres costing £1 million a month are lying empty due to the late delivery (3.5 years and counting) of their new IT system. At current (vague) estimates it won’t be ready until at least 2011 and is running £300 million over budget.

What strikes me here is that it’s not just all the money that’s being wasted, but the human effect these huge failures are having. Organisations are told to prepare themselves for new IT systems which don’t arrive or work as they need to, leaving them unable to do their jobs at all. It is tragic that in some cases this has led to real misery and even worse.

In other news we got a bit of press coverage in Computing.co.uk

What else can I do?

Contact Edward Leigh, head of the Commons Public Accounts committee who has reviewed many of the disastrous IT project and would no doubt be interested in your views.

Contact your MP and let them know how you feel about all your money being wasted.

If anyone has any good ideas on how we can either get more publicity for the petition or the cause itself, please get in touch.


That is all for now.

A call to action to UK software developers to stop your money being wasted

As I write, the petition to demand the UK government reviews it’s outdated I.T. project processes has been going for a week and has 193 signatures.

Am I disappointed? Far from it. The signatories list reads like a who’s who of people in the UK who care about software. Among the countless thought leaders, authors, conference speakers and influential bloggers, signatories includes:

  • Steve Freeman, winner of the Gordon Pask award and author
  • Rachel Davies, director of the Agile Alliance and author
  • Karl Scotland, founder member of the Lean Software and Systems Consortium.
  • Mike Hill, conference chair for SPA
  • Giovanni Asproni, conference chair for ACCU
  • Keith Braithwaite, conference chair for XPDay

Lets face it, this is never going to be a populist campaign. The simple matter is no one else is going to tell our government that there’s a more effective way to manage software*. It’s certainly not in the interests of people like BT and Siemens to stop signing multi-million pound contracts and I’ve no doubt there are very few people working in an advisory manner to the government on I.T. strategies who are particularly aware or interested in the now well-established and highly successful Agile umbrella of ways to build effective software, both on time and on budget.

So it’s up to us to highlight this situation. No one else is going to do it for us. As member of the software development community in the UK, your money is not going towards hospitals or schools, your money is being wasted on failed I.T. projects and will continue to be wasted** until our government stops naively signing off massive contracts for hugely optimistic and unrealistic projects.

I’m calling on everyone involved in software development in this country to do more to try and raise the issue to the level of visibility it deserves:

  1. Sign the petition if you haven’t done so already
  2. Write to your MP informing them about the petition and personally demanding a review. I’ve written a sample letter here which you can use as a template, but you should try to use your own words as much as possible otherwise it’s likely they will ignore it. Some more tips are available here.
  3. Blog about the petition. Tell people to sign it and email their MP and blog about it too. Twitter is great but blogging is better.

Nothing is going to change unless you get involved and demand your hard earned cash is better spent.



* An open letter was written to the Government by a bunch of academics about the problems with the NHS I.T. project, but was woefully misguided asking to see, among others, documents showing the “detailed design” and “technical architecture” for what must be the most idealistically naive and over-ambitious software project ever undertaken.

**According to IT Jobs Watch the average salary for a developer in the UK is £37,000 which means that, on average, they will contribute around £6,000 per year in tax. We’ll also say for the sake of argument that our average Joe works 40 years in his/her lifetime so in total he/she will pay £240,000 in tax. It would take 100,000 developer lifetimes to accrue the estimated £26 billion that has been wasted so far on failed Government I.T. projects.

Sign my petition to the PM to demand the UK Govt. reviews it’s failed IT processes

The Independent newspaper recently reported that the UK government has wasted £26 billion of it’s tax payers money on IT projects which have, “run millions of pounds over budget or have been cancelled altogether”.

£26 billion!

Of the projects mentioned in the article I’ve particularly been following the massive NHS balls up for some time and it’s quite clear that most of the reasons it has failed so badly can be attributed to following Waterfall type project management processes, dooming these behemoth’s to failure from the outset. The only value these projects are delivering is lining the pockets of companies like BT and Fujitsu who’ve landed most of the contracts for this work. There’s no doubt that most of the other cash sink holes mentioned suffer from the same problems* (it was the UK government that created PRINCE2 project management after all).

I find this totally unacceptable, especially when we now know that there are now well-established alternative approaches to the way these projects are managed which would have likely saved the tax payer an absolute fortune.

Keith Braithwaite has also blogged his views about the Government IT failures here.

I’ve created a petition on the Number10 website asking the Prime Minister to  demand a review of the out-of-date manner in which government IT projects are undertaken. I urge you to sign it and Tweet, blog, Facebook this to everyone you know**:

http://petitions.number10.gov.uk/ITProcessReview/

Thank you.

Update: If you don’t think it’s worth signing as it will have no impact have a look at this article on the BBC about the UK Goverment’s support for IE6


*Ironically the National Audit Office are currently producing a (delayed) report on the NHS IT project. They still advocate the Waterfall Approach according to this document found here. XtC members are in the process of writing to them about this. That letter can be found here.

**UK residents only. I ‘ve been involved in these petitions in the past and if they get enough support they do get responded to.


Less interface intensive dependency injection (C#)

In a study session at work last week we were having a discussion about how with dependency injection you can end up with loads of anaemic interfaces. Arguably these interfaces provide little value. However in C# at least there’s an alternative (thanks Josh and I think also Joe Campbell for this idea) – instead of taking an interface for a dependency in the client’s constructor, use a delegate instead.

So, instead of this “poor man’s” dependency injection example from my last post:

public interface IUserPaymentRepository
{
     void MakeTransaction(Price amount);
}

public class TrackPaymentActivity
{
     private UserPaymentRepository _userPaymentRepository;

     public TrackPaymentActivity():this(new UserPaymentRepository())
     {
     }

     public TrackPaymentActivity(IUserPaymentRepository userPaymentRepository)
     {
          this._userPaymentRepository = userPaymentRepository;
     }

     public AttemptToPayForTrack()
     {
          ......
          _userPaymentRepository.MakeTransaction(trackPrice);
          ......
     }
}

you can do this:

public class TrackPaymentActivity
{
     private Action _makeTransaction;

     public TrackPaymentActivity(Action makeTransaction)
     {
          this._makeTransaction = _makeTransaction;
     }

     public AttemptToPayForTrack()
     {
          ......
          _makeTransaction(trackPrice);
          ......
     }
}

So how do you test this? Mocking frameworks don’t (and probably couldn’t) support delegates so you’ll need to create an interface which has a method with the signature of the delegate, but only for testing purposes:

internal interface ITestPaymentTransaction
{
     void MakeTransaction(Price amount)
}

[Test]
public void Should_Take_Correct_Payment_Amount_For_Track_From_User()
{
     IUserPaymentRepository mockedTransaction =
               MockRepository.GenererateMock();

     new TrackPaymentActivity(mockedTransaction.MakeTransaction)
               .AttemptToPayForTrack();

     mockedTransaction.AssertWasCalled(transaction => transaction.MakeTransaction(expectedAmount));
}

In most situations I think this is preferable. You’re still having to create an interface, but it’s not creating noise in your production code. It also means you can’t use an IoC container, but as I said in my last post, in many situations you probably don’t need to anyway.

Not so poor man’s dependency injection

Uncle Bob’s written a post explaining why he tries to be very sparing with the use of IoC containers. I couldn’t agree more. Overuse of IoC containers can end up with a huge amount of indirection and noise in compared to the value they may provide*.

In my mind, the main benefit of dependency injection is testing and is crucial to being able to do TDD. If you do TDD you want to test one thing at a time (one logical assertion per test). If you find you need another piece of logic which is not the responsibility of the object you’re testing you don’t carry on writing reams of code until your test passes, you create a stub for the piece of functionality, make your test pass and only then consider implementing the stubbed out code.

I’ve always been a fan of poor man’s dependency injection. I can’t find any good examples on t’web so I’ll give an example (in C#). Poor man’s basically means having a default parameterless constructor and an overloaded one which takes the dependencies. The default constructor calls the overloaded one with concrete instances of any dependencies:

public interface IUserPaymentRepository
{
     void MakeTransaction(Price amount);
}

public class TrackPaymentActivity
{
     private UserPaymentRepository _userPaymentRepository;

     public TrackPaymentActivity():this(new UserPaymentRepository())
     {
     }

     public TrackPaymentActivity(IUserPaymentRepository userPaymentRepository)
     {
          this._userPaymentRepository = userPaymentRepository;
     }

     public AttemptToPayForTrack()
     {
          ......
          _userPaymentRepository.MakeTransaction(trackPrice);
          ......
     }
}

This allows you to call the parameterless constructor in your production code, but the overloaded one from your tests. I guess this is where it gets it’s bad name as test hooks are pretty scorned upon and there’s no denying that’s what’s going on here.

Here’s the thing – in many of the situations where you need to inject a dependency it’s for one piece of behaviour and there’s no decision going on to determine which object you need for that behaviour – you know there’s only one place in your code base that has that functionality. In other words, the dependency is still there! It’s just that by using an IoC container you’ve made it magically look like it’s decoupled. With poor man’s it’s easy to see these dependencies but if you’ve palmed it all of to an IoC  you’re gonna end up having no idea what’s using what until you fire up the good ol’ debugger. What’s worse is your code metrics won’t pick it up giving you the impression your code is in a better condition than it actually is.

Of course there is a time and a place for IoC containers. It’s just that it’s probably a lot less than you thought. If there’s a decision to be made at runtime about which type that impliments IUserPaymentRepository should be used or there’s more than one member on the interface (suggesting that it is stateful) then an IoC container would be desirable, otherwise I’m often quite happy being poor.

 

 

*I actually don’t have a huge amount of experience with IoC containers, but that’s because like Uncle Bob, I’ve always tried to avoid them until absolutely necessary, however I do have first hand reports (within orgs I’ve worked for) of where IoC abuse has caused very expensive problems.