Startup Suicide—Rewriting the Code

1/25/11Follow @sgblank

The benefits of customer and agile development and minimum features set are continuous customer feedback, rapid iteration and little wasted code. But over time if developers aren’t careful, code written to find early customers can become unwieldy, difficult to maintain and incapable of scaling. Ironically it becomes the antithesis of agile. And the magnitude of the problem increases exponentially with the success of the company. The logical solution? “Re-architect and re-write” the product.

For a company in a rapidly changing market, that’s usually the beginning of the end.

It Seems Logical

I just had lunch (at my favorite Greek restaurant in Palo Alto forgetting it looked like a VC meetup) with a friend who was technical founder of his company and is now its chairman. He hired an operating exec as the CEO a few years ago. We caught up on how the company was doing (“very well, thank you, after five years, the company is now at a $50 million run rate,”) but he wanted to talk about a problem that was on his mind. “As we’ve grown we’ve become less and less responsive to changing market and customer needs. While our revenue is looking good, we can be out of business in two years if we can’t keep up with our customer’s rapid shifts in platforms. Our CEO doesn’t have a technology background, but he’s frustrated he can’t get the new features and platforms he wants (Facebook, iPhone and Android, etc.) At the last board meeting our VP of engineering explained that the root of our problems was ‘our code has accumulated a ton of “technical debt,’ it’s really ugly code, and it’s not the way we would have done it today. He told the board that the only way to to deliver these changes is to re-write our product.” My friend added, “It sounds logical to the CEO so he’s about to approve the project.”

Shooting Yourself in the Head

“Well didn’t the board read him the riot act when they heard this?” I asked. “No,” my friend replied, sadly shaking his head, “the rest of the board said it sounded like a good idea.”

With a few more questions I learned that the code base, which had now grown large, still had vestiges of the original exploratory code written back in the early days when the company was in the discovery phase of Customer Development. Engineering designs made back then with the aim of figuring out the product were not the right designs for the company’s current task of expanding to new platforms.

I reminded my friend that I’ve never been an engineering manager so any advice I could give him was just from someone who had seen the movie before.

The Siren Song to CEO’s Who Aren’t Technical

CEO’s face the “rewrite” problem at least once in their tenure. If they’re an operating exec brought in to replace a founding technical CEO, then it looks like an easy decision – just listen to your engineering VP compare the schedule for a rewrite (short) against the schedule of … Next 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 www.steveblank.com. Follow @sgblank

Single Page Currently on Page: 1 2

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

  • Jake

    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.