Comment by Tiquor | Hacker News Reader

Comment by Tiquor | Hacker News Reader

Parent Full thread

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.

The number is not about "Should I rewrite or not", I should have made that clearer in the post.

Some thoughts

"Is low good or bad?"

As it is a risk in your book, first it's good to know. Is low good or bad? Depends on your strategy. Fast time to market with a rewrite after Series-A, low seems good. Low growth, tight margins low seems a high risk to me.

"What is the value of being able to migrate to another system?"

I don't know why people migrate or are forced to migrate, it depends on your situation I guess. From following HN people seem to rewrite their systems all the time. From working at startups as CTO, one reason to rewrite seems you can't get the current technology stack stable (e.g. Web Framework does not scale for your type of business) or you can't migrate your tech stack to a new version.

"In additon, this number has no intrinsic value component."

Often when talking to CEOs they are suprised that they need to pony up some millions to completly rewrite a system because it can't be upgraded to a new version of X, which they haven't got in their budget and planning of their long term margin growth.

You're right about the 'improve' wording, I'll think about a more neutral term. Same I'll rethink the KPI wording.

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.

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

Reply on news.ycombinator.com