4 ms·

> 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

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

nkurz 7y ago
> 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.
- tomnipotent 7y ago
  > 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?
  - nkurz 7y ago
    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.
    - TikiTDO 7y ago
      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.
noonespecial 7y ago
Trick question. False dichotomy. Its the company that spent those years best serving their customers with whatever technology worked for them.

nkurz 7y ago

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

tomnipotent 7y ago
> 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?
- nkurz 7y ago
  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.
  - TikiTDO 7y ago
    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.

noonespecial 7y ago

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