Why rewriting code can be startup suicide

(Editor’s note: Serial entrepreneur Steve Blank is the author of Four Steps to the Epiphany. This story originally appeared on his blog.)

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.

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":240751,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,","session":"B"}']

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.

I recently had lunch 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.) 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,” he said. “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 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.”

“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.

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":240751,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,","session":"B"}']

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.

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 adapting the old code to the new purpose (long.)

In reality this is a fools 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 one-year rewrite into a multi-year project.

[aditude-amp id="medium2" targeting='{"env":"staging","page_type":"article","post_id":240751,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,","session":"B"}']

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 don’t care whether it’s 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.

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.

[aditude-amp id="medium3" targeting='{"env":"staging","page_type":"article","post_id":240751,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,","session":"B"}']

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 suggested 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. Making the wrong choice on this sort of matter can crater a company. This was something that was worth the brawl at the board meeting.