Taking the road less travelled by

Back at the beginning of 2003, Red Gate was doing well: our products were selling, we were profitable, and life was good. Our SQL Comparison tools – version 2 – were popular and, I thought, fully baked. There was very little more we could do with them. Sure, they were a bit slow, there were a few bugs, and we had some competitors snapping at our heels, but there was nothing dramatic that we could add to the products.

We needed a new product. Something that would take us to the next level.

So we had a brainstorming session. Simon and I got everybody together – there were around 20 of us at the time – in a room and we spent an hour writing ideas on post-it notes and sticking them to walls. All good, non-judgemental, brainstorming stuff. At the end of the hour we gathered up the notes, categorised them and got judgemental. Should we do a lint tool for SQL Server, or a test management tool, or something for Oracle or DB2? These were all possibilities, but none of them really inspired us. So we took the easy option and decided to rewrite our existing tools. We threw away all the VB6 code base and started from scratch in C#.

On paper, this was a really stupid thing to do. A classic, unforced error that's killed, or scarred, companies such as Borland, Netscape, Wordstar and Ashton-Tate. Microsoft even took a stab at bizarre self-harm with their initial attempt to write Longhorn (now Vista) from the ground up in .net.

It was one of the best decisions we've ever made.

With the version 2 tools we'd coded ourselves into a dead-end. To get dramatic results sometimes you need to take dramatic action. To get out of that dead end – to radically improve the products, our customers' lives and, ultimately, Red Gate's sales – we needed to do something beyond the incremental. And that dramatic action was to throw away several man-years of work and start afresh.

But that's hindsight speaking. In reality, we rewrote the tools because we lacked the imagination to do anything grander. It was a lucky mistake. If we'd been more adventurous or had had more vision – if we'd tried to break into new markets or create new tools – then Red Gate would probably have been doomed.

Here are a few things I learnt from this.

Firstly, it illustrates how companies abandon profitable markets too quickly. This is, according to some people, one of the classic reasons that companies stall.

Secondly, sometimes it's right to throw away a successful product and start again. Apple did this with Mac OS X, and Microsoft with Windows NT. It's hard, and you're going to irritate some of your customers, and there's a good chance you'll fail, but it can – occasionally – be the right thing to do. If you're down a blind alley, or if the platform you're targetting is changing, or if inaction (which is, don't forget, a decision as much as action is, just easier) is clearly going to lead to failure, then it's an option you should at least consider.

Thirdly, the important decisions aren't always the ones that seem important at the time. Looking back on this decision, it was one of the most important ones that we ever made. But it didn't seem that way back in 2003. There was no sense of urgency, no feeling that this was a decision that could make or break the company. But it was. Not in the dramatic sense of a cause with an immediate effect, but it set us down a path that branched slightly off the alternative and, over time, that route diverged to take us in the happier direction.

It's the third point that interests me right now. So, this week's question of the week is "In building your business, was it obvious when a decision you were making was crucial, or were the forks in the road only obvious in hindsight?" $20 of amazon vouchers will go to the best answer. Post on the Business of Software social network.

Liked this post? Then follow me on Twitter.