Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Makes me think of the Ship of Theseus.[1] How many changes can you make to legacy code and still consider it “legacy”?

[1] https://en.m.wikipedia.org/wiki/Ship_of_Theseus



In many places, infinitely many; legacy is just a convenient word meaning "we know it's old and bad, but we're keeping it."


Legacy doesn't always mean bad. It may have an older architecture or have some constraints that aren't always a problem. I work a few different product designs but they almost all come from a legacy product. It's not a bad legacy design, it does what it's supposed to within the environment it was designed for. Customers still buy the legacy design. It's cheaper and doesn't have the flexibility or add-on features of the newer designs so if they don't want them or can't use them, they'll buy the legacy product.


>”we know it’s old…”

I think the point I was trying to make is if a substantial amount has been changed, on what basis is it still considered “old”?

If every plank and nail of the ship is replaced during it’s voyage, is it still the same “old” ship that disembarked?


Philosophical Gedankenspiele aside, there are differences between a ship and software. I can best speak to the software side, as I'm not a man of the sea. For once, a ship has to carry its own weight, so you cannot without limit load more and more onto it, or replace parts by heavier parts. With software "evolving" (rather poor but common terminology, I know) in tandem with new hardware, on the other hand, programmers get more space and faster processing every year, so they are less constrained and can postpone radical but scary/risky refactoring. There is no force to radically take out old code, you can comment out a bit here and there and add lots of new fixes and extensions, increasing complexity and technical debt every year, every decade. The OP also mentioned underfunding of the organization, typically the budgets only permit small incremental changes to "keep the ship running": there is no possibility to start a fresh/modern implementation with a separate team in parallel due to the mind-boggling cost.

It would be interesting to run a diff of snapshots of any software in 1960 and its 2060 version, if e.g. SABRE or the IRS system may last that long.


And its worked for 60 years. I would take that over anything else.


Even if you replace every board in the ship, it's still constrained by its original design. These software systems could be similar in that even if every line of code were replaced, architectural patterns, file formats, etc. that were created for the original system will continue to influence the current design.


Or ribosomes in every living thing translates mRNA into protein. Over three billion years of generic evolution the ribosome amino acids differ considerably between far apart species, yet retain their function.

Before DNA sequencing became efficient, a particular protein inside the ribosome was used to study genetic divergence.


>Even if you replace every board in the ship, it's still constrained by its original design.

Is it though? Or are you assuming it has to be replaced life-for-like? If so, why don't we apply the same to software? I don't think that constraint is a given with hardware. Is a remodeled house constrained by it's original design? It seems to come down to how much you want to invest in "refactoring" the old house.

Your comment made me think of the evolution of the F/A-18. The new variants are utterly different than their original, yet are still technically the same airframe.


one word: 737MAX


Care to elaborate? I’m pretty familiar with the issue, but not sure what through line you’re making


> The new variants are utterly different than their original, yet are still technically the same airframe.

This is what Boeing had in the 737MAX. It was a different aircraft, but it looked like the 737-800.


The MAX was under an amended type certification, so they were acknowledging the changes. Boeing didn’t follow their own rules regarding safety design (like redundancy on critical items identified on their hazard analysis)




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: