At first glance, this allows a suite of automated tests to be run against your code – the idea being that you have proof that your system does what it is supposed to. Bugs are caught early and, most importantly, a new feature cannot break existing features without you knowing about it.

But there is a much bigger advantage to behaviour-driven-development.

The very act of writing your tests before writing your code clarifies what you are trying to achieve and results in designs and code that are actually simpler – and hence easier to maintain.

I was reminded of this when trying to build a data importer. My colleague wrote a huge piece of code that seemed to work at first. But upon further investigation, it appeared to get some internal references wrong – and as the import took an hour to run, debugging became a pain.

So I started over. I wrote out a series of names for my specification: it should import a single product, it should import all variations of that product, it should import the images for a product, it should update an existing product.

These bullet points are a simple description for what it was supposed to achieve.

I then implemented the first bullet point in code – I took a copy of the import file, stripped out most of the data till I found a relevant piece, loaded that and then called the importer. My test just checked the results and ensured that the results were what was expected. The first run failed – because I didn’t have any code in my importer. But I implemented the simple “import a product” case and the test passed. Then I implemented the second bullet point in code. The first test passed, the second failed. I added the code to get the new test to pass – two passing tests and a very simple piece of code for the importer. Continue till all the tests were implemented – fantastic. The importer worked. But the most important thing – because it was built incrementally, it was simple. Even better, if it did start getting messy I could rewrite and rearrange the code to simplify it – and still be sure it was working as the tests proved it.

Writing the tests does not take much time – in fact it saves time as you have to explain to yourself what you are doing before you begin. But even more importantly, it results in clean, simple code. Which saves even more time (and money) in the long run, as that becomes cheaper to maintain.

Luckily, this helpful flow-chart helps you decide what to do next.

One of the major trends in software development at that time (at least for desktop applications) was to offer options – make it configurable and you can please everyone. And you can then sell “consultancy days” as it takes two weeks post-installation before the thing is usable, as you tick all the right boxes and choose all the right options. It also means you can say “hmm, well, there are eight different ways to do that, each with different pros and cons” (as opposed to saying “we can do exactly what you want” or “no, sorry, we don’t do that”).

So this was a big complicated software project; large enough that no one person knew it all the way through, with a variety of different architectures in-built (COM objects is how you do this stuff; oh no, now it’s COM+, now it’s ADO-disconnected and so on).

But we were only a small company. At its largest there were probably ten people working on the product at any one time. However, if you read the company communications you could never tell – it was all the bland, marketing-droid, use three-hundred-words-when-one-would-do style. Our email signatures had the sixteen paragraph disclaimer – “this is only intended for the intended recipient and if you are not its intended then wipe your memory immediately and burn your computer to prevent accidental ingestion”. This worked so well, some of our customers were amazed when they found out how many people we actually had – they thought we were a multinational with hundreds of developers across thousands of countries.

Over the years, we would consistently come across a single competitor – let’s call them Crump Builder. We poached our sales director from them, so we had a pretty good idea of what they were capable of and how they worked. We were small fry, they had funding and a team several times bigger than ours. They had also been going longer than us, so they had an even bigger set of preferences, options and modules to choose from. Most of the time, the sales process would come down to a choice between Roloduck and Crump Builder, and in the vast majority of cases, the prospect would choose Crump Builder.

At the time, I thought this was because we were behind them. They had the more polished, more finished product that did more and went further. But, since the demise of Roloduck (the company went bust recently) I’ve had to revise that view. You see, one of Roloduck’s old customers has chosen Crump Builder as the replacement for their now defunct Roloduck system. And she said that Crump Builder simply does not do a lot of the stuff that they need, whereas Roloduck does.

This news amazed me. Why did we consistently lose out to Crump Builder in those countless sales pitches?

Having thought about this, the only reason I can come up with is that we were not playing to our strengths. We were chasing their tails all the time. “We know they do X and we don’t yet; but we will soon”. “Yes, their version is pretty slick and ours is a bit clunky”. We were trying to present ourselves as their equals, equivalent in size and structure, in fact bigger than them in size and structure. But, because we were smaller, we were being found out. Not once, in our competitive analysis did we say “they are strong there, but we are strong here, so we should push this instead”. We should have pitched it as “we are the small guys – meaning you will get personalised service”, “our bit isn’t finished yet, so we can tailor it exactly to how you need it”

This is exactly what we have planned for our new venture. There are only two of us, so you will have the focussed attention of at least 50% of the company. We can’t afford lawyers or committees, so all the personality won’t be mangled out of our communications (bad jokes and all). And as we’re only small we can’t afford any waste, in either resources or time. So we will do what you need in the quickest, most efficient way possible. It will not work for everyone, but it will work fantastically for some. Those are our strengths and we will play to them.

Suppose you’ve been working in branch X and you’re about to merge those changes into branch Y …

• work in branch X and make your commits as needed
• switch to branch Y git checkout Y
• compare the differences between X and Y git log Y..X – the order here is important; it is merge-target..merge-source
• merge the changes from X (merge-source) into Y (merge-target) git merge X

Even better, before doing the merge, while you are still in branch X, you can squash multiple commits into a single one. This way, branch Y, when you examine the log, has a single entry “implemented feature X”, instead of thirty-five entries all related to feature X in some way.

• examine the log git log or even better git log --pretty=oneline
• choose the commit that immediately precedes the one that starts your piece of work (probably the last one before you branched to start work on feature X)
• start an interactive rebase session – this is git-fancy-talk for picking some commits and typing a message – git rebase -i THE-COMMIT-ID-OF-THE-COMMIT-YOU-SELECTED-ABOVE
• Your favourite editor (or nano) will open listing the commits for feature X – edit the word “pick” to “squash” for all except the top entry, save and exit
• Your favourite editor will open again – again showing your commit messages – add a line at the top stating something like “implementation of feature X” and leave the list of individual commits on separate lines below it (adding in a Fixes #123 or whatever your issue tracker demands as the last line), save and exit
• Now if you do a git log you will see a single commit with a nice “implementation of feature X” log message
• And you’re all set to merge to your master branch without cluttering its history with a long string of commit messages

From the customer’s point of view it’s pretty essential. You need to know how much you are spending before the work begins so you don’t get stung.

From the developer’s point of view it’s pretty difficult to do because you don’t know how long things will take until you know what you’re building. And you don’t know the details of what you are building until they become apparent, which is normally while you are doing the work.

For this particular client I wanted to get this piece of work out of the way as quickly as possible and the requirements were deceptively complicated. As trying to deal with intangibles is a recipe for disaster, and time was short, I was pretty sure that whatever estimate I came up with would be totally inaccurate.

So to deal with the intangibles I thought I may as well get stuck in with the actual work. And what’s the first thing that I do? Write a cucumber story.

I went through the requirements documents (which after weeks of to and fro were actually quite detailed and refined) and broke it down into four features, each with a number of scenarios. Each scenario was then broken down into individual steps – however, I did not write any step definition (ruby) files. This is cucumber as customer documentation, not as integration testing.

We agreed that the features met the requirements (the client was very impressed with the level of detail and the clarity that cucumber offered) and I simply went through each feature, scenario and step and came up with a price for the step individually. It’s still guesswork, but it’s guesswork on a small scale, so you’re less likely to be way off. Total the lot and there’s your estimate.

And even better, once the client has agreed the price and you’ve started development, you’ve got a development plan, a measure of progress and proof that it all works – all just a simple rake features away.

Image by lemon drop

One is a statement of opinion, the other is likely to get people’s backs up. Words and phrasing are important to people.

It’s why naming in computer science is hard.

It’s why people are better than machines.

But personally, what I like best about it, is that the entire site was built, from original idea to launch in less than five days.  

Last weekend, Caius and I had chatted about how we needed to test our stuff against Ruby 1.9.  John suggested automatically downloading and testing gems and reporting the results back to a web-site “a bit like the wine project does”.  David popped up in our Jabber room a couple of hours later saying “I’ve had an idea … isitruby19.com … list stuff that does and doesn’t work with ruby 1.9″.  Jeremy liked the idea … “I could probably skin it tomorrow night”.  

And so an evening of hacking by David gets a basic framework in place – he pulls the gems from Rubyforge and adds a comments model.  I take over on Monday, putting a basic HTML interface together, with gravatars and captchas, which Jeremy then makes look nice.  A blind alley over user registration, a few problems with Ferret, but by Tuesday we were pretty much done.  Deploy to the live site on Wednesday and then we just needed to test a few gems to seed the display.  Come Thursday and we all tweet about the new site … and isitruby1.9.com is launched.

From our point of view, it was great to do.  We still had our normal “day” jobs to deal with, but the excitement of a brand new project (with the added pressure of knowing that there were probably other people with the same idea looking to launch soon) was fantastic.  

And there’s still loads to do (as you can see from the discussion ongoing on the Brightbox forums) but I have to say I’m really pleased with how things have worked out so far.  We kept it agile, we kept it focussed and we kept it fun!

On Sunday morning, I awoke to find an email from a web-site monitoring service that I use, stating that a client site was down. The email was sent at 5am. It was now 10am and I had no computer, a mere GPRS connection and a hangover. Not good.

However, I fired up TouchTerm (an SSH client) on my iPhone and connected to the server in question. Connect OK. Good. Then I type sudo monit status to find out what state the server is in. All services running OK. Then cat /etc/apache2/sites-enabled/rails-mysite. This lets me examine the web-server configuration file; and I can prove to myself that I had set up aliases for the site (so that the same site is also available on an alternative web address). I then used Mobile Safari to connect on the alternative addresses and everything works fine. Lastly, I write an email to the client stating that the site is down but nothing at my end is wrong – could it be a DNS problem?

iPhone with TouchTerm

Later that day I got an email from the monitoring service stating that the site had returned. And on Monday, the client tells me that their registrar had had a failure and all of their domain names had gone down for the day.

Still, I think that’s pretty good; Sunday, with a hangover, pro-actively investigating a fault on a customer’s server, on a telephone and an antique net connection.

Brightbox Messages between myself and John Leach

Sometimes you have a moment where you know that you’re on the right path.  

I was hunting through an archive of work done for Brightbox and found this message trail.  I had just tracked down a bug and posted a small screenshot of the fix.  

John’s response let me know that this would be a great place to work.  

Sometimes, it just feels right.