the more we rewrite software, the more its true identity is revealed.
Theseus was the mythical king and founder of the ancient Greek city of Athens. The people of Athens greatly respected his ship and kept it in service for many years after his death. As the ship fell into disarray, parts of the ship were replaced until no original components remained. Was this the same ship that Theseus sailed? This question, and the more general question of whether or not an object that has had all of its components replaced remains fundamentally the same thing, is known as the Ship of Theseus Paradox. (I previously wrote about this and other "strange loops").
Rewrites are not just inevitable. They are part of the job.
But software rewrites are more like changing an airplane's parts midflight than replacing planks on a ship. As a result, the standard advice has been to avoid complete rewrites, mostly stemming from Joel Spolsky's Things You Should Never Do, where he attributes Netscape's demise to a decision to rewrite.
The world has changed a lot since Netscape. Software is delivered through software as a service rather than licensed binaries. Many services run in the cloud rather than in a customer's data center. Service-oriented architectures provide stronger internal API boundaries that create smaller surfaces to re-implement. As a result, shipping Thesean software is significantly easier than before.
What does it mean? It means that we should pursue rewrites and pay down technical debt aggressively. We should design modular software with the intention that it will be updated or replaced. We should treat API design as a one-way door and implementation as a two-way door (see Bezos on decision-making).
Thesean software should be the norm of how we design and develop software. But, ironically, the paradox works in the opposite direction for software: the more we rewrite software, the more its true identity is revealed.