Hacker News Reader

Comment by randallsquared | Hacker News Reader

> consider two different companies. One spends the next 5 years committing to those languages and eco-systems that have been built for the era. The other spends the next 5 years using Docker so they can keep using script languages from the 1990s. Now it is the year 2023, and a crisis happens at both companies. Which of those two companies do you think will be more ready to adapt to the crisis?

Presumably the one that doesn't have to rewrite everything that they just wrote from scratch to avoid Docker.

View on HN

Trick question. False dichotomy. Its the company that spent those years best serving their customers with whatever technology worked for them.

> Presumably the one that doesn't have to rewrite everything that they just wrote from scratch to avoid Docker.

I think that's too simplistic. Larry is right that a company who manages to survive 5 non-productive years rewriting everything in a "better" ecosystem will likely be in a better situation than the company trundling along with ever increasing technical debt.

The problem is that the conservative company without the major rewrite is more likely to make it through (at the least the first few of) those 5 years. So Larry's not wrong --- he just might be making some unwarranted assumptions.

> rewriting everything in a "better" ecosystem will likely be in a better situation than the company trundling along with ever increasing technical debt

So you believe that code with no-to-minimal history running successfully will be better than dated-but-proven code that has been running for over a decade?

There are good and bad ways to do such a rewrite. If the 5-years are spent completely isolated from the world, then no. But if the system has been used in live production for a couple years before the 5-years is up, then yes. I think "technical debt" is a really large hindrance, believe that even long lived systems are still full of hidden bugs, and would probably bet on the newcomer with a clean codebase if they can get far enough along to have a working system.

That really depends on quite a few other factors: how big is the team? What development methodology do they use? Does the leadership understand how to manage and direct a rewrite? Are there people that understand the full scale and scope of the system? Does the system interact with legacy components that can't be modified? Are there political factors in play? These are just a few of the questions that can change the outcome of any given rewrite.

You mentioned hidden bugs, but what about hidden "features" that may be a critical part of existing business processes for core parts of the company? Developers really like to believe they are at the center of the wheel due to the complex work they do, but a lot of the time they are not the ones that actually create the cash-flow.

I've been part of rewrites that have succeeded tremendously, but I've also been privy to utter failures that have cost millions, and led to entire teams getting sacked.

Reply on news.ycombinator.com