Startup Suicide—Rewriting the Code


(Page 2 of 2)

adapting the old code to the new purpose (long.) In reality this is a fool’s choice. The engineering team may know the difficulty and problems adapting the old code, but has no idea what difficulties and problems it will face writing a new code base.

A CEO who had lived through a debacle of a rewrite or understood the complexity of the code would know that with the original engineering team no longer there, the odds of making the old mistakes over again are high. Add to that introducing new mistakes that weren’t there the first time, Murphy’s law says that unbridled optimism will likely turn the 1-year rewrite into a multi-year project.

My observation was that the CEO and VP of Engineering were confusing cause and effect. The customers aren’t asking for new code. They are asking for new features and platforms –now. Customers couldn’t care less whether it was delivered via spaghetti code, alien spacecraft or a completely new product. While the code rewrite is going on, competitors who aren’t enamored with architectural purity will be adding features, platforms, customers and market share. The difference between being able to add them now versus a year or more in the future might be the difference between growing revenue and going out of business.

Who Wants to Work on The Old Product

Perhaps the most dangerous side-effect of embarking on a code rewrite is that the decision condemns the old code before a viable alternative exists. Who is going to want to work on the old code with all its problems when the VP Engineering and CEO have declared the new code to be the future of the company? The old code is as good as dead the moment management introduces the word “rewrite.” As a consequence, the CEO has no fallback. If the VP Engineering’s schedule ends up taking four years instead of one year, there is no way to make incremental progress on the new features during that time.

What we have is a failure of imagination

I suggested that this looked like a failure of imagination in the VP of Engineering – made worse by a CEO who’s never lived through a code rewrite – and compounded by a board that also doesn’t get it and hasn’t challenged either of them for a creative solution.

My suggestion to my friend? Given how dynamic and competitive the market is, this move is a company-killer. The heuristic should be don’t rewrite the code base in businesses where time to market is critical and customer needs shift rapidly.” Rewrites may make sense in markets where the competitive cycle time is long.

I suggest that he lay down on the tracks in front of this train at the board meeting. Force the CEO to articulate what features and platforms he needs by when, and what measures he has in place to manage schedule risk. Figure out whether a completely different engineering approach was possible. (Refactor only the modules for the features that were needed now? Rewrite the new platforms on a different code-base? Start a separate skunk works team for the new platforms? etc.)

Lessons Learned

  • Not all code rewrites are the same. When the market is stable and changes are infrequent, you may have time to rewrite.
  • When markets/customers/competitors are shifting rapidly, you don’t get to declare a “time-out” because your code is ugly.
  • This is when you need to understand 1) what problem are you solving (hint it’s not the code) and 2) how to creatively fix what’s needed.
  • Making the wrong choice can crater your company.
  • This is worth a brawl at the board meeting.

Single PageCurrently on Page: 1 2 previous page

Steve Blank is the co-author of The Startup Owner's Manual and author of the Four Steps to the Epiphany, which details his Customer Development process for minimizing risk and optimizing chances for startup success. A retired serial entrepreneur, Steve teaches at Stanford University Engineering School and at U.C. Berkeley's Haas Business School. He blogs at Follow @sgblank

Trending on Xconomy

By posting a comment, you agree to our terms and conditions.

One response to “Startup Suicide—Rewriting the Code”

  1. Jake says:

    This is the never ending “Big Bang” versus incremental evolution question.

    Steve correctly points out the “Big Bang” is usually a disaster. If it ever gets released it is years late and 10x+ the original budget. And then everyone agrees it wasn’t done right, is obsolete and should be replaced.

    What software developers don’t want to start fresh? Don’t let them. Insist on development of a bridge architecture that allows incremental development of new features/functions/platforms and replacement of older modules.