Pair Programming: Introduction

I’ve had the opportunity to have worked with many different people pair programming wise over the last year or so, and having seen it done in several different ways thought it would be interesting to work through some of my thoughts about this Extreme Programming (XP) originated practice.

First of all it seems to me that pair programming is a technique that is used with a lot more frequency at ThoughtWorks than at any other IT organisation.

Obviously I do not know every IT organisation in the world, but based on discussions at the ALT.NET UK conference I went to last weekend; it certainly came across to me like that. The difficulty in getting clients and/or management to see the value in having two people on one machine was the main factor mentioned as proving problematic.

I have been working for ThoughtWorks for 18 months now and have been pairing for all but 3 of those months. Perhaps contrary to popular opinion, not every project is a 100% pairing one.

I’ve paired with people for 20-30 days at a time, paired with people for 1 day at a time, paired with people who have been pairing for years, paired with people who are pairing for the first time, and all in all it’s been fun.

I now find writing code far more enjoyable when working with someone else, motivated by the opportunity to bounce ideas around and come up with better solutions.

The biggest benefit for me of pairing is that you have to vocalise your ideas to your pair. This massively reduces the chance of going down a dead alley as a ‘wrong’ idea would have to somehow make sense to two people, which is much less likely to happen.

Equally, when done well, you end up thinking a lot more about why you are doing things e.g. why should that method go on this class, should we introduce a new service, why are we testing it in this way, should we be testing it another way etc.

On the flip side there are times when you just want to look up something which interests you but isn’t totally relevant to the current task and that has to be placed on the backburner for the time being. Pairing can also prove very tedious when doing fairly trivial tasks such as changing configuration files; although of course it does help if every knows how to do this so pairing on these tasks does provide some benefit.

I will cover some of my other thoughts in future posts.

Inheritance and Delegation

One of the major learning points this week at TWU has been understanding when it is appropriate to use inheritance and when delegation is the better choice.

I had heard stories about how inheritance could be misused but I didn’t think I would be stupid enough to fall straight into that trap! We were taught the concept using ‘Measurement’ as the problem domain. So to translate the previous sentence into English: The aim was to design classes which could handle old school measurement types such as Inches, Feet, Yards, and so on.

I went about the task by first creating a base Measurement class and then created Inch, Foot and Yard as sub classes of this. The code looked pretty slick to me and I was quite pleased with how it had turned out. I was feeling pretty confident that I had nailed the objective of the session. Alas, it was not meant to be!

Upon reviewing the code my partner and I had created, one of the trainers pointed out that the sub classes did not actually do very much at all. They were effectively useless classes and there was barely any difference between them! One of the other requirements for the code was that it should be possible to compare an instance of the Inch class with an instance of the Foot class, an instance of the Yard class with the Inch class and so on. No problem I thought and promptly created methods called ‘ConvertToFoot’ in my Inch class and ‘ConvertToInch’ in my Foot class.

One of the cardinal sins of object orientated programming had been committed! I now had 2 methods which did almost the exact same as the other for no additional benefit. What if there were 100 different measurements? That would mean 99 different conversion methods each to convert to all the other types of measurement. Clearly not an optimal solution - I had taken the bait and fallen into the trap of over use of inheritance.

Anyway, the lesson of the session was that in this particular case it was better to use delegation or composition. In this example it means that there is only the need for one Measurement class, each instance of which comprises of a Unit object. The concept of a ’slug’ was introduced - no not one of those nasty little insects, but in this case meaning an instance of an object with a private constructor and one public static instance. In other words slugs are like a poor man’s Singleton. The code looked something like this:

class Unit { public static readonly Unit INCH = new Unit(1); public static readonly Unit FOOT = new Unit(12); }

This made it far easier to add future measurement types, and meant that only two classes were needed instead of a potentially infinite amount.

I read an interesting article on this topic by Robert Martin, titled ‘Template Method & Strategy: Inheritance vs Delegation’ which explains the reasoning much better than I have here along with a code example.

Watching a master at work

I’ve always found it fascinating watching people who really excel in their field going about business, be it footballers, tennis players, actors, whoever.

This week at TWU I’ve been playing around with some Ruby on Rails as I mentioned in the previous post, and yesterday I had the opportunity to watch one of the leading figures in the Ruby on Rails field at work. Take a bow Obie Fernandez, who gave several of the TWU attendees a demonstration of how to develop applications using Ruby on Rails. It was actually bordering on the severely impressive watching the speed at which he thought through concepts and then transformed them into code.

I also realised that the way I’d been using the language previously had been dubious at best. I hadn’t realised that you can take care of database creation without using MySQL Administrator, nor had I realised quite how ‘clever’ Ruby on Rails is at mapping database tables to models created in the application.

It was almost painful watching how simple it is to do arduous tasks, such as creating textboxes and drop down boxes, in Ruby on Rails and it almost made me want to weep as I recalled the many hours I’ve spend using PHP and C# tweaking interaction between code and stored procedures/queries.

So +1 for Ruby on Rails and I certainly hope to improve my ability with it over the next few weeks.

First thoughts on Ruby…

I’ve heard a lot about Ruby on Rails over the last couple of years but I’d never really been intrigued to get it set up on my machine and ‘have a play’ with it so to speak.

It turned out to be a relatively painless process and after following the instructions on the official site I had it all setup within about half an hour which was a record for me for getting a development environment setup. With a bit of help from the Pragmatic Programmers Guide to Ruby I managed to get some basic pages setup. The design of the URLs and the separation of the code is actually fairly intuitive. Ruby on Rails uses the MVC (Model - View - Controller) Architecture/Design Pattern very strictly and the code for each of these is written in a separate file.

One aspect of this that made sense to me as a PHP programmer was the way that the URLs in Ruby on Rails are constructed in a “/[controller_name]/[action]” format. I also like the fact that everything in Ruby on Rails is an object, even such things as integers and strings. It takes a bit of getting used to but after using it for a bit it seems counter intuitive to do it any other way.

I don’t think I’m about to become an advocate for the use of Ruby on Rails for every development project I work on - I’m still a big fan of C# and the .NET platform and I find it unlikely that I’ll change my mind in the near future but we shall see!