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.

But they are wrong.

Mozilla should be worried. Even Apple should be worried. But Microsoft should not.

You see, if Chrome is successful it will take search revenue (from the little online search box) that Google pays to Mozilla and Apple every time you click on an advert (as opposed to a search result).

But that’s not Google’s aim.

Their aim is “fire and move”.

Just as Microsoft prepares an assault on Google’s search and advertising business, Google distracts them with an assault on the Windows desktop. A classic Microsoft ploy (see the Win16 API, the Win32 API, the .Net API) turned against them.

So, how do you respond to fire and move? Well, that’s the real question.

It’s not finding a push-over client.  The client is busy and has their own problems to solve.  

It’s a combination of organisation, management and communication.  

Stay organised.  Always know what is outstanding, who is doing it and when it will be done.  

Manage your client.  Software projects are strange in that so much of the process is intangible until final delivery.  So manage your client.  Guide them to where you need them to be.  Make it easier for them to be a good client than a bad one.  It won’t always work – sometimes there are clients who simply don’t fit – but for the most part it’s your job to keep them on the straight and narrow.  

Talk to them.  Always keep them up to date.  Respond to questions as quickly as possible – at least within a day.  Even if the answer is “I’m a bit busy at the moment but I’ll get back to you before the end of the week”.  With all these intangibles flying around the client looks to you to keep them grounded.  

A perfect example of this is a recent job I have been working on.  My client was a marketing agency.  Their client was a small business – we mainly dealt with the MD and Head of Marketing.  There was also a couple of people from an SEO involved.  

For some reason every job I did for them seemed to take a lot longer than the estimate.  I got the feeling that, despite the eventual, fantastic, results, there was a lingering undercurrent.  So I persuaded them to organise the project through good old Basecamp.  

And the reasons for the delays became immediately apparent to everyone, from the SEOs to the MD.  What would start out as 8 To-Do items assigned to me quickly became 30-odd To-Do items, assigned to everyone else involved – as questions were raised, slight changes in direction were needed and designs were reworked.  

With all this stuff out in the open the next phase of the project went much more smoothly than the earlier ones – because I managed the client into organising things through a better channel for communication.  

Because, the way I look at it is, at the end of the day, it’s your job, your client and your responsibility to keep things ticking over.  Don’t you think?