One of the most difficult aspects of Agile development to explain to the uninitiated is the concept of Pair Programming.

Imagine the scenario: you go up to the Project Manager and state that you’re going to roll out Agile, and as a part of this you will be pairing up with your favorite Code Monkey and sitting in front of one PC discussing the same code. *** Cue long hard stare from the PM ***

But to anyone who’s had first hand experience of Pair Programming they’ll tell you that tasks are generally completed much quicker and with more focus than the sum of the time otherwise used by the two programmers.

This concept was “brought home” to me recently at a party I was having at my house. My wife and I had about ten of our close friends around for food and drinks, and the conversation (after a few beers!) turned to our slow-filling toilet.
Now to put this whole thing in context, my wife has been nagging me for the best part of 2 years to fix this toilet and, for one reason or another, I’ve just never got around to it.

So as the conversation dragged on the men of the group decided to have a look at the toilet and find out what was wrong. I took the top off the tank and explained that the float arm was not allowing the water to fill quick enough and, being Men, we all stuck our hands in and started pulling pieces out, turning levers and pulling things out, and then…

BOOM!

The pressurised water inlet pipe shot into the ceiling followed by a jet of water soaking all of us in an instant. I stuck my finger into the inlet pipe and shouted to my wife to shut off the water.

Suddenly a two year D.I.Y. job had turned into a Saturday night emergency!

Once we had turned off the water supply we all set about unbolting the toilet from the wall, disconnecting the inlet pipe, draining the tank, etc. Fortunately I also had the spare part for the inlet pipe so we were able to completely repair the toilet.

Now what the hell has this got to do with Pair Programming?

Well the fact that 3 drunk guys on a Saturday night can repair a toilet using their combined effort/knowledge/determination shows me that when something needs to get done then it can be done. We all knew how to do the task, we all knew why it had to be done, and since we were a team, we all kept each other focused.

So the next time your Project Manager questions the value of pair programming, remember my toilet!

Hearing about the sad passing of Neil Armstrong, the first man on the Moon (do I even need to remind people of that?), my fascination with the Apollo projects of the 1960’s and 70’s is rekindled yet again.

Does anyone wonder how these missions came to be so successful in a time when technology was so primitive that a modern digital watch has more processing power than the Apollo 11 Lunar Module?

Having read numerous books on the subject, I believe their success is due to one thing.

They simulated EVERYTHING.

Every detail of the mission was performed in minute detail on the ground where it was safe to do so and problems could be caught, analysed and solutions formulated before launch day.

We do the same when unit testing our code. We simulate the building of our software, we test it, and we fix problems all in the safety of our Development Environment before we launch it into the Live system.

Ok, you’re going to get the odd Apollo 13, but if you’ve taken these basic steps in stabilising your code the chances of a successful project are greatly increased.

But wait, what exactly is it we’re trying to do here in our jobs as producers of useful software? We want our customers to feel comfortable using our software, we want the software to be functional, we want it delivered in the shortest possible time.

I once started a software project a few years ago and the analyst gave me a 300 page specification! It would have taken me at least two weeks to read it, and another week to reread it and understand it.

Why was it so long? Was the Analyst trying to prove something? Was he paid by the word? Or was he trying to justify his position as if the bigger the document the more secure he felt in his job and, therefore, happy that he was providing a quality service.

The fact is that if the Specification was 5 pages long, it would have taken him a fraction of the time to write, it would be easier to understand, I would have started sooner and the project would have been finished sooner.

It sounds like the beginning to a Tom Jones song, but it’s the most common question I get asked when I introduce unit testing to someone.

So here’s the definitive answer…

How do you know your code works?
You’ve written a package/procedure and, ok, you may have run it in SQLPLUS, TOAD, SQL Developer, but does it do what it’s meant to do? Have you tested it from all angles? Does it fail gracefully if there’s an error?

It works today but will it work tomorrow?
Ok, so you tested it when you wrote it, but will it work tomorrow? Next week? At the end of the project when you’re migrating to the Live Environment? During the development phase your database may change frequently and invalidate packages. Therefore, you need to run your unit tests frequently to verify that everything is ok.

Detect your errors early
If there’s a bug in your code you must detect it early. This ties in to the concept of Daily Build and Continuous Integration whereby your application is built and tested frequently so that you can see errors as they happen and fix them early, not when it’s too late!

Does it replace User Acceptance Testing? Of course not.
It’s true to say that a comprehensive unit test can do much of the functional business logic testing, but we can never totally replace the UAT stage.

Don’t cheat with your Unit Tests!You could sit and create lots of tests that simple verify that an object exists, but is that a relevant and accurate test? Not really.
A unit test should test the functioning of your code. Does your code do what it’s meant to do?

Peer Review
Following on from point 5, we should review each other’s code making sure that our tests are accurate, relevant and appropriate.

There may be many other reasons why unit testing is a good idea, so please feel free to comment below.

Don’t get me wrong, I like Lego too, I like the modular nature of it, I like the way you can take small units and combine them together to make bigger, more complex things. I like the way the blocks snap easily together and I like the distinct colours each block has.

The problem is this. When I look at my son’s bedroom it reminds me of some of the software I’ve seen in previous job’s. No structure, no organisation, things in places where they shouldn’t be, basically a mess.

When software is designed like this it becomes unmaintainable and un-scalable.

It makes my toes curl when I see HTML/CSS code embedded in a PL/SQL package or Javascript code in an APEX page region.

So I said to my son that I would get him a little unit of drawers so he can keep the Lego in that and he can organise it by colour and type. This seemed to make some sense to him since he could then easily find pieces and build bigger and better Lego creations in a short time.

So far he hasn’t tidied his Lego into the drawers, but one day I believe he will. One day the light bulb will appear above his head and when it does I’ll take a photograph of his room and post back here.

Years ago a boss of mine once commented on what would happen to the project if I was run over by a bus.

Thinking about it I then decided to take it as a compliment. Apparently he was suggesting that I had sufficient importance on the project that if I was to “kick the bucket” in a horrible public transport accident, the project would be in trouble.

One of the great things about Agile development is the concept of pair programming.

Every so often this is made glaringly apparent to me when I sit looking at some code with a blank expression on my face and time slips away.

Sometimes you can be hypnotised by code and your brain goes round and round in circles.

So, thinking like an Agile developer, I call over a friend to look over the code with me. As I sit and explain the problem, as if by magic, the answer begins to crystalise before me. And my friend has done almost nothing!

The simple process of explaining and discussing a problem with someone often brings about the solution.

Within 10 minutes, my code problem of two days was solved with a couple of lines of code and an exception handler!