
CEO to CTO: What Is Your RewriteRatio? - _Codemonkeyism
http://codemonkeyism.com/ceo-to-cto-what-is-your-rewriteratio/
======
mchahn
> 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.

Uh, all of these are supported quite well. Each has a place in the ecosystem
and will be around for a long time. Anyone who considers rewriting an app
because a new one of these comes out has a serious problem. My old apps use
older ones and my new use newer. What is the problem?

~~~
karmajunkie
I think the problem is punctuation; reading that sentence it looks like "Web
frameworks [that] are no longer supported[.] In JavaScript we have seen
Backbone, knockout, angular, ember, and react in rapid succession..." Which is
a true statement, though you're right that it looks as though the implication
is that they're no longer supported when in fact it's simply that the older
frameworks are losing momentum and mindshare.

------
_Codemonkeyism
Author here, any feedback appreciated.

~~~
Tiquor
Is this really a KPI? It is really only measurable, not directly improvable.
In addition, what does "improving" it mean? Is low good or bad? If we had a
highly functional system and were growing 1000% then this number goes way up.
Is that bad? This number, IMO, communicates very little between a CTO and CEO.

In additon, this number has no intrinsic value component. What is the value of
being able to migrate to another system? Who cares? Rewrite for what? Does
code rot? Are there bad spots like an apple? Does recreating the apple keep
bad spots from being created next time?

There are only 4 states for a rewrite value judgement:

1\. App is small and provides little business value..so who cares.

2\. App is big, but low values so what's it matter.

3\. App is huge and high value so better be very very careful.

4\. App is small and high value, so why?

Your ratios restate that and provide no additional information in the only
state that matters which is number 3.

~~~
dragonwriter
It's not even measurable: its the ratio of two numbers, neither of which is
actually measurable.

OTOH, the cost to migrate can never be greater than the cost to rewrite from
scratch, since rewriting from scratch is a method of migrating.

And I'm not sure this ratio is ever meaningful. I get that the idea is to have
a simple, scale independent measure of the impact of technical debt, but the
proposal here is neither objectively measurable nor meaningful, IMO, in that
role.

~~~
_Codemonkeyism
You're right, I had a paragraph is on getting the number but this is obviously
thin ice, so I dropped it for now. I'm out of ideas on how to measure it, I
probably would ask a group of developers, let them make an educated estimation
and then make a best effort estimation based on their answers, perhaps
something like the Delphi Method [1]

"OTOH, the cost to migrate can never be greater than the cost to rewrite from
scratch, since rewriting from scratch is a method of migrating."

Interesting point. I need to work on the definitions as obviously 'migration'
is not clear cut enough.

[1]
[https://en.wikipedia.org/wiki/Delphi_method](https://en.wikipedia.org/wiki/Delphi_method)

