Ship of Theseus
Hey!
Welcome back to another week of musings. The past week has been very hot around North California. I hope the weather is better where you are! And that you're able to rest during the weekend.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- I tried Sayaka Murata's cafe-hopping writing routine 🖋️☁️ I recently came across this Author/YouTuber who replicates writing routines from famous authors! It's a very cozy watch if you're into that.
- I began watching Mechanical Keyboard content again, and alexotos is such a great watch!
As I continued my journey to track and reduce tech debt around the organization, I came across this concept of the "Ship of Theseus."
In Greek mythology, Theseus, mythical king of the city Athens, rescued the children of Athens from King Minos after slaying the minotaur and then escaped onto a ship going to Delos. Each year, the Athenians would commemorate this by taking the ship on a pilgrimage to Delos to honour Apollo. A question was raised by ancient philosophers: After several hundreds of years of maintenance, if each individual piece of the Ship of Theseus was replaced, one after the other, was it still the same ship?
I found this interesting because I feel this happens constantly with software engineering. If you have a service running continuously over a long period, say 10 or 20 years, you've changed much of the code over the years, refactored it, introduced tests, updated dependencies, etc.
Also, suppose your organization grows or re-org fast enough. In that case, the original team that built it is no longer present, so whatever original context it was built upon no longer exists.
While stretching the allegory a bit, it can be used as a tale about not creating something new from scratch to replace the old software. Instead, software should be updated meticulously and intentionally, little by little.
The other aspect here is the software's "identity" from the perspective of a new service (writing it from scratch), which would be different from the original service. In time, it would be lost in the same way as the original service.
I'll leave the philosophical question to you, but what concerns us the most is the practical aspects of this question.
Software, as the ship, requires maintenance for the foreseeable future, the pain of success, if you will. I think about this when seeing 30 or 40-year-old code bases written in Perl or C.
When people originally wrote it (and are now retired), they probably didn't think much about how their function for handling cents would be there so long afterward.
Once we introduce a "hack" or "quick fix," that code becomes load-bearing via Hyrum's Laws. So be wary of what you code!
Since original teammates will not be there after so much time, all these hacks become Chesterton Fences, which will require a significant amount of time to debug, triage, and repair or remove.
In general, I don't think I have a point beyond saying that:
- Refactors should take a piece-by-piece approach
- Think about each piece of code you write!
You don't know which parts will still be maintained 20 years later!
Your turn!
Let me know how you handle refactoring code or paying tech debt by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others