Hacker News Reader

Comment by Wildgoose | Hacker News Reader

The Japanese have a philosophy whereby they will rebuild a shrine every 20 years. The knowledge of what is necessary remains current, and understood. And the shrine continues in its purpose.

Perhaps we should consider how we can regularly rewrite different parts of our software ecosystems using new languages and approaches while preserving the essential knowledge and security aspects of what we have already built?

The important part isn't the language that the code is written in, it is the full understanding of the problem and thus the solution provided.

View on HN

I don't think new languages and tools are necessary in all circumstances, I imagine part of the process of rebuilding every 20 years is to not forget how to build in the first place.

Being around for the frontend engineering revolution taught me what it means for an industry to forget how to build, and have to re-learn many already hard learned lessons.

But maybe I'm looking at it wrong, and it was that re-learning process that was the re-building after all? I don't know. All I do know is that you rarely get enough time in software to master your tools before everything changes, and you have to build the same old software requirements in brand new ways.

Isn't that what the Frontend Ecosystem has been doing, but instead of 20 years it is more like 20 months?

IMHO a more realistic idea is to treat the COBOL code as the "idea" or "essence" of the shrine which eternally remains the same, and only rebuild the "physical presence" of the shrine, which would be the environment the COBOL code runs in (e.g. modernize the hardware, the operating system, the debugging/development tools and virtual environment (== emulator) the COBOL code runs in, but don't rewrite the COBOL code itself).

But then you have solved nothing...

Maybe, but "nothing" is still much better than making things worse (first, a rewrite usually needs to be bug-by-bug compatible, so you have almost no leeway to "improve" the product, second, new code has new bugs that need to be found and fixed, don't underestimate the amount of work that has gone into a 50 years old code base that still does its job).

Basecamp does this.

Every ~6 years they completely rewrite Basecamp from the ground-up and sell it as a new product management tool. They are currently on rewrite #3 and rewrite #4 will be released next year.

https://signalvnoise.com/posts/3856-the-big-rewrite-revisite...

The only difference to your analogy is that they continue to support the old versions of Basecamp so that if a customer doesn't want to migrate to the current version, they don't have too.

Reply on news.ycombinator.com