CEO to CTO: What is your RewriteRatio?

I’ve been thinking a lot about the interaction of CEOs and CTOs over the last years. On that topic I gave talks, educated CEOs and held seminars. What type of interactions do CEOs have with technology? What are KPIs that make sense? What are levers forthe CEO? What questions should a CEO ask? What should CEOs know about technology?

I still have the feeling after many years of technology success for many CEOs technology is a black box, that either works or explodes, with nothing in between. Do I get a good return of investment from IT? Should I have more developers? When talking to CEOs many feel not in control when it comes to technology.

Recently after talking to Jens Schumann from OpenKnowledge about the life cycle of frameworks, I had an idea for a lever and a possible KPI around technology. This would be the ratio of the effort of migrating the current system to a new technology vs. rewriting the system from the scratch.

Say the ratio is 50%, this means migrating this system to a new technology is 50% of the effort of writing it new. 150% means migrating the system is more expensive than writing the system from scratch. I would assume many systems are between 80% and 120% with the majority at 100%. If no guidance is given, most code is written in a way that ties it tightly into frameworks.

RewriteRatio obviously depends on the technology the system should migrate to. e.g. migrating from Scala Lift to Scala Play is easier than migrating from Ruby with Rails to Javascript with Node. If you switch the programming language it’s probably always the same as writing from scratch, as essentially this is what you do.

Why should a CEO ask this question? Systems come to the end of their life cycle, or parts of these systems do. Web frameworks are no longer supported, in Javascript we have seen Backbone, Knockout, Angular, Ember and React in rapid succession, with older frameworks massively losing momentum and community. So this always is a hidden risk in your books potentially in the millions. Rewrites also have a huge impact on the delivery of new features. Often rewrites block the delivery of new features for months or even years. During some company phases rewrites are no problem and even planned for, e.g. during a first to market phase financed with external money. During some other phases rewrite costs can be painful, e.g. when there is no longer hyper growth and profit margins are thinner. The less they are, the better.

If not asked, CEOs often assume there is no need for a complete rewrite but only upgrades or migrations. Technology people often think everyone knows that we need to rewrite sooner or later. Or they just assume they’ll leave the company before that date. So often code is written in a way where migration is not easily possible.

The RewriteRatio can also be used as a communication device and alignment between CEO and CTO. e.g. the goal could be to maintain a 50% rewrite ratio. The CTO then manages according to this corridor. Developers know how much effort to put into abstracting technologies or packaging business logic away with anti corruption layers or if fast and furious is ok with the CEO (100% RewriteRatio).

RewriteRatio is just one lever or KPI which helps CEOs manage IT. I will explore more in upcoming posts.