I don’t think we should always pair, all the time. There, I said it.

I’ve been working in “agile” teams for several years, and since starting at ThoughtWorks one practice that we always seem to use and promote is pair programming.

I think pair programming is great, for a few reasons:

  • Knowledge sharing and avoiding silos or single points of failure.
  • Bringing people up to speed – especially for new team members and juniors.
  • Building relationships and communication. I found after my first project as a developer, I had much closer relationships with the developers I’d paired with than any of the other people I’d worked with as a BA on previous projects. This makes for better teams.
  • Collective code ownership – if you’re not the only one working on the code, you can’t feel too much like you own it.
  • Better decision making – by having two people discuss and agree on a solution.
  • Faster problem solving – especially in complex systems.
  • Promotes consistency of code style and standards, especially if the pairs rotate.

Yay! So should we always pair all the time?

I would actually say No to that. Having spent a decent amount of time pairing, and experienced many eager and reluctant pairs, been the “junior” and the “senior”, on both work and fun projects, I’ve found there are definitely some frustrations.

  • It’s exhausting. If you’ve ever done a solid day of development on a difficult project with a pair, you probably came away shattered.
  • After working with the same person for a long time, both people stop learning from each other. A lack of rotation also means you still end up with knowledge silos – just made up of two people rather than one.
  • Sometimes, pairs are well matched, but more often one person is significantly faster, usually because they’re more knowledgeable about the codebase or the work being done. Over time, this can be frustrating.
  • Pairing on simple problems can feel like a bit of a waste. I’ve definitely been in this position towards the end of a project.
  • Some people just don’t like pairing. Even I don’t like pairing when it’s all the time.
  • I’m not convinced that pairing significantly reduces the number of bugs when you practice TDD and have a good suite of automated tests. The navigator may see obvious errors first, but more often than not the automated tests find the more interesting ones before the code is even checked in (although it does help having two people to solve them)

My last project was a two-person delivery gig. My colleague Hari and I discussed upfront whether we would pair, and in the end we didn’t – for some of the reasons above, but also because some of the benefits of pairing were much less on a two-person team:

  • We didn’t really have a complex problem to solve – it was a reasonably simple, small website.
  • Six weeks of pairing with me would probably have driven poor Hari insane.
  • We were sat directly next to each other and were constantly discussing the project, so we didn’t need to work on the same code to make ourselves communicate or share decisions.

As well as agreeing to talk a lot, share important decisions about the code design, and refactor each other’s code where we saw a need to, we also decided to rotate the stories we were working on to try and avoid any silos or single points of failure.

So how did it work?

In retrospect, I do think it was the right decision. I discovered that I actually enjoyed working alone (which felt like a terrible admission for a while) – although I still prefer to work in a larger team with some pairing, I now believe that developers also need a break from pairing some of the time. It’s a matter of finding the right things to pair on, and the right time to work alone. For us, I think pairing would have slowed us down.

However, at the end of the project, I discovered that there were definitely some gaps in my knowledge around the things that Hari had implemented. We were probably not rigorous enough about recognising when we did need to pair and doing it, and towards the end of the project as time grew tighter we did not swap stories enough. We were pretty good at changing each other’s code, and I think that in general our coding style was fairly consistent – although this was probably the case before we even started working together, it seems to be a ThoughtWorks “thing”!

From a quality perspective, only one bug was reported in UAT, and it wasn’t even much of a bug (calendar starts on the wrong day) – and I think this is because we were pretty rigorous around our automated testing practices, including integration and acceptance testing with Cucumber.

In future, I would still promote pairing but perhaps a little bit less dogmatically than I used to. I want to make sure I continue to use it when there are clear benefits, and especially when introducing new team members or for complex problems. However, I would like to try and ensure developers have more breaks from pairing and that work is organised to allow for that, as well as a good degree of rotation. How often the rotation happens, and what proportion of time is spent pairing versus working alone, I think should always be dependent on the team, the problem at hand and the situation.

CoffeeScript

On my last project, we decided to try out CoffeeScript. I was pleasantly surprised at how easy it was to get started with it and how nice it was to use, instead of JavaScript.

I’m a fan of object-oriented JavaScript code, but there are many different ways to structure the JavaScript (using the prototype, or constructing an object each time with private methods, to name a couple). I’ve seen several medium-to-large JavaScript codebases that use a range of techniques with no consistent pattern. CoffeeScript solves this problem by giving me a standard way to create new classes (which IMO is much easier to read and understand than JavaScript methods defined on the prototype). It’s performant (since the methods are defined on the prototype) and tries to produce easily-readable, JSLint-able code. (I had my first look at the JavaScript produced by ClojureScript last night, and it’s definitely much harder to navigate than the code produced by CoffeeScript).

Here are some tips to get started:

  1. The back-end was .NET and we were working in Visual Studio, so we used the free Web Workbench plugin to generate javascript files from our coffee files. It updates the files automatically at every save, which was really handy. Errors appear in the output window for Visual Studio.
  2. If you’re using the Node Package Manager, you can install CoffeeScript with that:
    npm install -g coffee-script
    You can then use the coffee command to compile coffeescript files:
    coffee -c myfile.coffee
    This also works with wildcards:
    coffee -c src/*.coffee

I was pretty amazed how easy it was to integrate CoffeeScript with any other JavaScript frameworks, including JQuery and Jasmine. Jasmine tests in CoffeeScript look like this:

What this means is that if you want to start using CoffeeScript, you can – you don’t even need to rewrite any of the existing JavaScript if you don’t want to.

In general, CoffeeScript reads much more like English than JavaScript – === is replaced by is, !== becomes isnt, you can use unless instead of if (!) and it also has Ruby-style string interpolation, just to name a few nice things.

We did run in to a couple of things that tripped us up, so here are some things to watch out for.

Classes are not global

Chances are, you’ll be creating classes across a number of files. If you just create your classes using class MyClass, you won’t be able to create one in another file by using new MyClass since CoffeeScript puts all the code inside a single file in a single closure (which is a Good Thing).

You can solve this by creating classes called new window.MyClass. However, the better practice is to use namespaces. We added a line to the top of all of our files to ensure the parent namespace was defined:


window.MyNamespace or= {}

Binding to this

You can access properties of the object with the @ symbol. Inside the javascript code, you will have a reference to this.propertyName.
However, for methods that are to be used as the targets of events, you will need to bind to the original value of this. CoffeeScript makes this easy, you just use => to define the function instead of ->.

Example of when you don’t need to bind to the original value of this:

Example of binding to an event target, when you do need to use the original value of this to access properties:

Is it worth a try?

I would definitely say yes! In particular, for larger JavaScript projects, if you don’t have an established consistent way of writing JavaScript, or if you’re writing object-oriented JavaScript code, it will probably simplify a lot of the code base and remove the danger of accidental bugs like creating global variables.

If you’re more in favour of functional-style JavaScript, or if you’re a JavaScript guru and just luuuurrrrve those curly braces, then you probably won’t get as much from CoffeeScript. Maybe you could try ClojureScript instead 😉

First steps with Clojure

Over the last year, I learned Ruby. I’m not amazing at it and there’s still a lot to learn, but I know enough to be useful with it. In the spirit of learning a new language every year, the next one I wanted to tackle was Clojure.

I also decided to try using Emacs, since I had heard the Clojure support was pretty good.

After installing Emacs on my Mac (which is running OS X 10.7), I spent the morning surfing teh interwebz and trying a few different things to get Clojure working. Here’s how it looked in the end:

  1. Install Emacs from here.
  2. Read the tutorial to understand the basic shortcuts (C = control, M = alt below)
  3. Install marmalade – inside the directory ~/.emacs.d create the file init.el and enter:

    (require 'package)
    (add-to-list 'package-archives
    '("marmalade" . "http://marmalade-repo.org/packages/") t)
    (package-initialize)

  4. Run M-x: “package-refresh-contents”
  5. M-x package-install starter-kit
  6. Install clojure-mode by pressing M-x package-install and choose clojure-mode.
  7. Install Leiningen by folling the instructions here: https://github.com/technomancy/leiningen
  8. Install swank-clojure: run “lein plugin install swank-clojure 1.3.3”
    Note – I initially installed 1.3.2 which gave me an error when I tried to run it from Emacs.
  9. Create a new project with Leiningen.
  10. Open Emacs, navigate to a project file and type M-x clojure-jack-in.

Once this was working, I also discovered a couple of key shortcuts that were really useful:

  • C-c C-k compiles the code in the current buffer.
  • C-x C-e executes the code in the buffer before the current line end.

Now I’m up and running, I’ve been able to complete all of the 4Clojure Koans at the elementary level. You don’t actually need to have clojure running locally, although I found it helped to figure out what was going on.

I’m also working on the Clojure Koans on github.

So far I’m finding both to be really fun and good learning resources ☺

Some of the best guidance I found

Finishing up with Io

As I reached Day 2 with Io, I continued to struggle with the syntax, in particular temptation to write object.method instead of dropping the ‘.’. I felt that I was starting to get some of the concepts of the language, the ability to rewrite core methods and override Operators.

However, I have also struggled throughout Day 2 and Day 3 with the lack of easily available documentation – the reference and guide on the main IO website did not seem to explain many of the things I needed to know, including how to read input from the console. I resorted in some cases to “cheating” by reading other people’s solutions to the exercises (although it’s not really cheating, since the point is to learn :)).

As I wrote my solutions, particularly the longer ones, they felt slightly clumsy – as though I wasn’t taking advantage of Io’s strengths. In the middle of Day 2 and start of Day 3, I really wasn’t enjoying working with the language, although by the end of Day 3 when I introduced the new Xml_Element object, it felt more natural. I’m glad I finished the chapter, although I’m still not really sure where I would use Io.

Overall, the main thing I’ve got out of the book so far is a greater understanding of meta-programming, which I’m hoping will help me take better approaches to new programming problems.

All of my solutions are on Github Gists:

Here are some highlights from the difficulties I ran into …

I was baffled for Day 2, Exercise 2 as to how to keep the original division method, but a quick internet search (and a minor cheat) revealed the solution: I needed to store the original division method in another variable:

When I reached Exercise 7, I discovered from other solutions that serialization in IO is actually really, really easy. All objects have a serialized method that writes it out to a string. When reading the object back from a file, all that was needed was the assign the results of the doFile("filename.txt") method to a new object. Writing to files is easy too – here’s the full solution:

For Exercise 8, I spent a considerable amount of time trying to find out how to read input from the console – turns out you can use File standardInput readLine. This gives you a string, so you need to use asNumber to complete this exercise.

Day 3, Exercise 1, was a massive struggle – at first I could not figure out how to pass the right indent, and I ended up looking around at some other examples before I figured out that I needed to:

  1. Write the parent node
  2. Add one to the indent
  3. Process the child nodes
  4. Remove one from the indent
  5. Close the parent node

I also discovered that using indent := indent + 1 doesn’t work – I guess you lose the reference to indent, so you need to do indent = indent + 1. Here’s the finished code:

In Exercise 2, I discovered after some internet searching and experimenting that Io has two built in methods: curlyBrackets (as used in the book) and squareBrackets – these can both be overridden to allow lists or maps, or anything else, to be created using {} or []. I guess this might be obvious to some people, but I was quite confused by it!

Here’s the list code:

The final exercise, adding attributes to the XML Builder, had me stumped for some time – in fact, I took a break from it overnight and a solution came to me in the shower :) My difficulty was figuring out when to write the contents of the XML node, I didn’t want a separate method but couldn’t write out the contents inside the loop.

The final solution still feels slightly clumsy but it does work (indents and all):

IO – Day 1

The group as a whole seems to have slowed down a bit on IO, with only a few of us sharing our Day 1 experiences. Installation has bitten a few people. I was lucky in that I was able to install it painlessly on OSX using Homebrew.

My next challenge with IO was figuring out the syntax for comments – turns out it’s a double slash: //

The homework: there was a lot of questions to answer, so I figured it was better to complete it in a blog post rather than a gist.

Stuff to find

Example problems
I wasn’t sure if they are looking for puzzles to solve, or problems with the IO codebase. I couldn’t find the former, but here are some problems with the codebase: http://en.wikibooks.org/wiki/Io_Programming/Pitfalls

Community
Yahoo group: http://tech.groups.yahoo.com/group/iolanguage/

Style guide
http://en.wikibooks.org/wiki/Io_Programming/Io_Style_Guide

Questions to answer

  1. IO is strongly typed. The following commented out code causes an error because “one” is not a number.
  2. All are true:
  3. Use slotNames:
  4. ::= Creates slot, creates setter, assigns value
    := Creates slot, assigns value
    = Assigns value to slot if it exists, otherwise raises exception

    The output of the slotNames in the code below reveals that Elf has the following slots: type, weapon, setWeapon, name

Stuff to Do

  1. To run an IO program from a file, just open terminal and type io filename.io.
  2. To execute the code in a given slot, simply call the slot.

Note: for the last piece of homework, I was trying to think of what to write code about. I recently moved into a new flat, and my new housemate has a small, very cute dog, who has just discovered a new game: fling his smackos under the bed, and then bark at it until she comes to retrieve it for him. I decided to write a very simplified version of that :)

Sydney Ruby on Rails User Group

I attended the Sydney Ruby on Rails user group last week. There was a pretty decent size crowd, and the talks were hosted in the upstairs room at the Trinity Bar and Grill in Surry Hills, with beer and food available from the upstairs bar. I was disappointed to see that there were only three girls there though, it would be lovely sometimes to not stick out so much!

The talks are short, only 15 minutes each which is perfect because there’s never time to get bored. It also means, however, that it’s difficult to get very in depth with anything.

First up was Mario Visic talking about using declarative steps with cucumber, which are far less detailed and attempt to describe the business requirement, rather than the imperative style which is more granular and contains scenario data. The arguments are that declarative steps will change less as the design of the system changes, and that business people can write them. More about declarative steps.

I have my reservations over whether it would actually reduce the overall volume of changes or just move them out of the steps. I’ve never known business people write steps (and in fact somebody asked the question whether Mario’s client had written any steps, to which he replied no!) and I would be interested to know what QAs think of this style.

It’s an interesting idea though and one I might try on my next project if I can.

Next was David Parry on CoffeeScript, something I’ve been wanting to try for a while. I learned that one of its aims is to produce perfectly JS-lintable Javascript, which is very cool. You can also convert existing Javascript into CoffeeScript to make the move across easier – I think the tool demonstrated was JS2Coffee.

I also learned that CoffeeScript puts everything inside an anonymous function, so calling functions directly doesn’t work. I must put some time aside to play more with it!

The last talk was about learning from some specific mistakes by Andrew Grimm, which included large classes and the importance of writing maintainable code. These are things that everybody should be aware of, not just Ruby developers!

Lastly there were a few five minute talks including quick tips by Scott Harvey – who mentioned the ‘grep’ method for arrays that I discovered through the Seven Languages book, and two interesting talks encouraging people to join entrepreneurial courses and start up weekends. Some of these are similar to the Launch 48 events I enjoyed in London, so maybe I’ll go meet some Aussie entrepreneurs soon!

All in all it was a fun night, I’m looking forward to the next one as well as the SydJS group next Wednesday!

Timing with Tomatoes

After attending some of the Personal Effectiveness talks at Goto; in Aarhus, I decided to have a go at using the Pomodoro technique. At a very basic level, using this technique means working for 25 minutes at a time before taking a 5 minute break, then repeating the pattern. After every four pomodoros, take a longer break.

Linda Rising in particular had talked about the need for regular breaks to ‘recharge’ our brains, and how this can actually make us more effective than working continuously without a break.

My pair agreed to give it a go with me, and in fact found an awesome Android app called Pomodroido, so we set off! We made an effort to get up and walk around during breaks, even if it was just a wander through the office.

Here’s some of my observations from the first couple of weeks we spent doing it.

  • Always knowing that you have a break coming up and how far off it is, makes it much easier to get through stuff – especially boring work, or things that you don’t want to do.
  • Knowing that you’ll be breaking from what you’re doing in 25 min made me focus harder on the work I was doing – as a consequence, by the end of the day, I was often pretty tired.
  • I was a bit skeptical about the longer break, but after four intense 25 minute sessions, I really needed it.
  • The greater focus also meant that I felt I was getting through more stuff than I would have otherwise, especially when I had a list of handover documents to write, which I might have dawdled over otherwise.
  • Getting up and walking around helped me stay alert, especially during the post-lunch afternoon slump.
  • Working with a pair helped both of us be more diligent about taking breaks, getting up and keeping going with the pomodoros.
  • It was useful to have an app – without that, sometimes it was harder to time the pomodoro, I often forgot to check the clock (although we sometimes forgot to start the app as well …!)
  • After finishing up on the project, I tried to carry on with the pomodoro technique while I was packing for my Australia trip, with mixed success – it’s less useful for running errands, for example! However, it’s definitely something I plan to try again on my next project, and for software development I think it has huge benefits.

Why Spike the Poodle?

My first blog was called Spike the Poodle. I’ve recently imported a lot of my old posts from my early agile experiences with Scrum, which made me smile and sigh :)

Here’s the original story of why it was called Spike the Poodle.

“Poodles come in different sizes. It’s not something I’d really given much thought to before. I’m not really much of a doggy person, but when I was younger, one of my friends had a miniature poodle, and so I always kind of assumed that all poodles came in about that size. No.

I attended a Scrum training course in March 2006. It was during this course that, for the first time, I felt that I really wanted to be able to blog and share my experiences of trying to implement what I’d learned back home, and to hear back from others who might be doing similar things.

In learning about estimating the size of project requirements, we undertook an exercise working in pairs to assign scores to different breeds of dog … Great Dane, German shepherd, Pekinese, Labrador, and … you’ve guessed it … Poodle. Without guidance as to what criteria to use, a group of eleven people will come up with some pretty imaginative ways to score different types of dog :) In our case, we decided to use the easy option (we were only given three minutes! And plus, we weren’t the only ones) and estimate based on size.

For most of the breeds it was fairly straightforward, but we disagreed on poodles. I had a picture in my head of a small fluffy thing about the size of two shoeboxes but my partner argued that poodles were more like the size of a Labrador.

So to put this back in the context of project requirements … we both understood different things by what had been described to us. Scrum offers a technique known called Spiking when there are unknown elements in the user requirements, and in the group discussion that followed the exercise, our trainer’s advice was that in this type of situation, we could Spike the Poodle in order to learn more about the requirement … and so the phrase was coined.

It was a funny moment in the course and made me smile to see it in the follow up email. Since the course was the inspiration for creating a site, I stole the phrase to use as a tribute to the newbie ScrumMasters who graduated with me in Manchester, and those who trained us.”

Seven Languages Week 1: Ruby

Week one of the seven languages is complete!

Having the support of the study group was great – motivating but without being too much. I was amazed at the breadth of the solutions, especially to the homework for Day 1 and Day 2.

Day 3, I was a bit underwhelmed by – the final part of the chapter introduced a lot of interesting techniques with meta-programming and modules, but the problem set didn’t really seem to challenge me to think too much about them.

The book encouraged me to look at the API to try and find solutions for different problems. Having the study group made this aspect even better, because we often found different things – for example, collect and zip methods for arrays. James in particular found some very short and neat ways to solve the problems.

Overall I think I like Ruby even more after doing this. It has so much “syntactic sugar”, and I definitely have a sweet tooth! Overall I’ve learned that while you can use Ruby to write programs in a rather boring, more Java-esque style, there is almost always a much neater, Ruby-ish way of doing it. I only wish I had more time and opportunities to learn it properly.

My highlights:

  • Day 1 reminded me of the usefulness of ranges
  • Quick ways to convert between hashes and arrays in Day 2:
  • Discovering the ‘grep’ method in Enumerable from James’ day 2 solution.
  • Finally getting a better understanding of modules (still far from perfect, but I definitely get them far better than before)
  • Learning the ‘zip’ method for arrays – although still not sure I completely understand how to use it!

My solutions are here: https://gist.github.com/jocranford

7 Languages in 7 Weeks – The Next Study Group …

I was inspired a while ago by Daniel Temme’s experience working through the book Seven Languages in Seven Weeks as part of a study group organised by Aimee Daniels, and together with James Doig (a colleague and regular pair on my current project!) we decided to start a new one. We’ve got a Google group and planning to use Google+ hangouts, blogs and twitter (with the tag 7languages7weeks or through this account).

We’ve agreed to kick off on October 24th with Chapter 1, which covers Ruby. I’ve had a sneak peek at the book, a bit of a giggle at the comparison of Ruby the programming language to Mary Poppins, the magic British nanny, and I’m excited now to get started. I haven’t done very much functional programming, and the book promises to challenge me, and to teach interesting aspects of each language. We’ve agreed to take it a little slower for the first couple of chapters and see how things go.

Our group has grown to around fifteen people, divided about half and half between ThoughtWorkers and Skyscanners, and also includes one post-technical project manager – very impressive! There’s still time to join, so please leave a comment or contact me via twitter if you’re interested.