The last two Tech Tuesdays were about choosing technology as a startup. Today we are talking about what to do once you are up and running. Let me start by categorically stating what you should never, ever do: rewrite everything from scratch. There is a terrific piece on why this is a bad idea written in 2000 by Joel Spolsky that you should go off and read right now (Joel is a very entertaining writer).

Etsy early on made this mistake and it almost killed the company. When I first invested in Etsy, the marketplace was already up and running and growing nicely month over month. The team felt they had learned so much and were so unhappy with the existing codebase that they decided that Etsy V2 would be written from scratch. This meant that known bugs in the existing system weren’t fixed which is not good. And of course as with every rewrite ever V2 dragged on much longer than anticipated. The delays compounded the problem of the unfixed bugs as the marketplace continued to grow putting huge pressure on the team as sellers grew increasingly irate (at one point I had to provide “shuttle diplomacy” between Brooklyn and Jersey City). In the end, Etsy rolled out a V2 that was much stripped down from its ambitious plans, just in the nick of time for avoiding a full blown meltdown.

So what should you do instead? Rewrite piecemeal. The image that people sometimes use and is quite apt is one of rebuilding a plane while in the air. You have to pick pieces that are small enough so that you can replace them in flight. This approach seems less efficient because you will have to write the new pieces to fit with the old ones and also modify the old ones to make it work (even though you already know that you will be rewriting those next). And you may not be able to get from where you are to where you want to be until many iterations. Yet, based on everything I have seen over three decades of being involved with commercial systems (meaning systems deployed in a commercial rather than academic setting) it’s the only viable approach. In upcoming Tech Tuesday posts I will have more to say about best practices for doing this.

The last two Tech Tuesdays were about choosing technology as a startup. Today we are talking about what to do once you are up and running. Let me start by categorically stating what you should never, ever do: rewrite everything from scratch. There is a terrific piece on why this is a bad idea written in 2000 by Joel Spolsky that you should go off and read right now (Joel is a very entertaining writer).

Etsy early on made this mistake and it almost killed the company. When I first invested in Etsy, the marketplace was already up and running and growing nicely month over month. The team felt they had learned so much and were so unhappy with the existing codebase that they decided that Etsy V2 would be written from scratch. This meant that known bugs in the existing system weren’t fixed which is not good. And of course as with every rewrite ever V2 dragged on much longer than anticipated. The delays compounded the problem of the unfixed bugs as the marketplace continued to grow putting huge pressure on the team as sellers grew increasingly irate (at one point I had to provide “shuttle diplomacy” between Brooklyn and Jersey City). In the end, Etsy rolled out a V2 that was much stripped down from its ambitious plans, just in the nick of time for avoiding a full blown meltdown.

So what should you do instead? Rewrite piecemeal. The image that people sometimes use and is quite apt is one of rebuilding a plane while in the air. You have to pick pieces that are small enough so that you can replace them in flight. This approach seems less efficient because you will have to write the new pieces to fit with the old ones and also modify the old ones to make it work (even though you already know that you will be rewriting those next). And you may not be able to get from where you are to where you want to be until many iterations. Yet, based on everything I have seen over three decades of being involved with commercial systems (meaning systems deployed in a commercial rather than academic setting) it’s the only viable approach. In upcoming Tech Tuesday posts I will have more to say about best practices for doing this.