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.
Simpol has just finished a long programme to re-write and enhance an old 16-bit product that had hit the buffers.
Details of our new RAD tools at: http://www.simpol.com
The new product will help create an application that run on many different Operating Systems without any changes.
In April we shall launch it and see if our persistence has paid off !
.
This strikes me as an often all too necessary step in technology product life cycle management. You had the indicators right in front of you:
* Product was good, but a bit slow
* Competitors nipping at your heels
* Coded yourself into a dead end
* Heavy reliance on VB6 (fast to prototype, slow and painful to upgrade and maintain)
Lots of folks from Seth Godin to Lawrence Friedman have pointed out that it is a common mistake to abandon existing customers and a known market in favor of a new product line and a new market. Sure, it’s exciting to do blue sky development and we all love to have the sky as the limit, but it is hugely expensive to break into a new market, with a new product to boot.
I’ll also kick on the idea that it was throwing “away several man-years of work” because Red Gate had internalized the lessons from Version 2. The architecture deficiencies, the language challenges, the coding dead-ends, the feature hacks, etc. You applied all those lessons when you created Version 3. Of *course* it was better!
So, I’ll agree that perhaps you did get lucky that you chose to make a dramatic improvement in your product by rewriting it. 🙂
The take away lesson for me would be to include product rewrite and over-haul in my product road map. The triggers for that action would be the things you identified that are bulleted above.
The mistake, to which you refer, would have been to select an incompatible architecture or technology “just ’cause”. Moving from VB6 to C# strikes me as a very rational technology growth choice.
Bravo!
When faced with a falling market, companies often look to do something radically different or new — even something outside of their strengths — to jumpstart revenues. Or, they try to invent something that nobody wants (think New Coke or the Porsche SUV).
Example now taking place: Noilly Prat is changing its U.S. vermouth formula from the one that has made it an essential ingredient in the classic martini. It will leave hundreds of thousands of dedicated customers behind.
About 8 years ago when I was running a traditional PR agency I had a staff meeting with this premise: “What would we do if there were no more trade publications”? Our bread and butter was placing press releases, case studies and editorials in targeted trade publications. We came up with a lot of good ideas, most having to do with establishing client credibility as self-publishers, essentially eliminating the middle man in conversations between a company and its customers. It’s a model I’m now using with clients, especially in those markets faced with a diminished number of credible publications. At the time, it was an exercise in looking ahead; now it’s become an essential part of my client strategies.
What does “coded ourselves into a dead-end” *mean*? I’ve never seen a program so bad it couldn’t be refactored into something good. Throw out a single file of source code? Sure. Throw out an entire working app? I don’t get it.
The reason we call it “software” is because it’s *soft*. You can rebuild the foundation while everybody’s walking around upstairs, if you want. Why would you tear down the whole building without needing to?
Sorry – I didn’t get what was so cool with re-writing your VB6 product in C#. What exactly benefits you got – easier to maintain, faster, etc?
Joel Spolsky wrote a famous essay about how big rewrites are nearly always a very bad idea. It would be quite interesting to hear what he has to say about this case. (Perhaps the only thing to say is, well, there are exceptions.) At Symbolics and Object Design, there were times when we rewrote modules, but never the whole shebang.
Neil,
What’s more interesting to me is:
1. Why did you make this decision in place of others? Did you go back to your customers? (focus groups#
2. What was the effect of this change? You talk about how great the decision it was but you didn’t outline the scale. Did you triple the sales? Did you stop the decline in sales? #competition stepping on your toes).
Or was it just because you wanted to sell a “cleaner and greener” app and the effect was simply that you now feel good about your architecture?
Eugene
“The Mythical Man-Month”, by Fred Brooks, Chapter 5, “The Second-System Effect”. ‘Nuff said.
Ken says “What does “coded ourselves into a dead-end” *mean*? I’ve never seen a program so bad it couldn’t be refactored into something good.” Well, I have! You should look at some old, old code that has been maintained for a long time.
The authors of Perl said this about the Perl 5 implementation, as long ago as 2001 (see http://ll1.ai.mit.edu). They concluded that were stuck, and needed a total reimplementation.
Some of the most extreme cases, there are plenty of mission-critical systems out there that nobody understands; they hire outside consulting firms to come in and figure out what the program is doing.
But it doesn’t have to be that extreme. There can be times when you want new functionality, and it’s pretty clear how the architecture ought to work to provide that and have everything be clean and orthogonal and so on, but the existing structure isn’t anything like that. You might be able to salvage some code, but a complete rewrite is necessary.
Joel Spolsky’s points about why complete rewrites are usually not a good idea are good points. But they don’t imply an absolute rule against rewrites. Costs and benefits must be weighed. It’s good to read Joel’s anti-rewrite essay, since he points out costs that you might have overlooked. But there are unquestionably cases where you just can’t keep going.
VB6 is a dead-end. If your last project was written in DBASEIV, no amount of refactoring is going to get you into the currently supported languages and frameworks.
I don’t know if Red Gate did a ground up rewrite, or a mere port though. If the code base was clean, I’d start with a port before more enhancement is done.