Write code that is easy to delete, not easy to extend (2016)

The unfortunate side effect of this (very good) advice is that all code that's easy to delete will eventually be replaced with code that's hard to delete (and thus will eventually be impossible to delete in order to be replaced with something better).

My favorite saying: “simple is robust” Similar in spirit to Lehman’s Law of Continuing Change[0], the idea is that the less complexity a system has, the easier it is to change. Rather than plan for the future with extensible code, plan for the future with straightforward code. E.g. only abstract when the situation requires it, encourage simple duplication, use monoliths up front, scale vertically before horizontally, etc. I’ve built many 0-1 systems, and this is the common thread among all…

Being on the other side of the recommendations in that article, I disagree. Do whatever you want for the pilot system but couple things that should be coupled in the real system. Let domain driven knowledge drive decisions on coupling/decoupling

I find the difficult thing with this advise is that people always want to skip step 1. From my experiance once you introduce the principle of refactoring repeated code into functions no one wants to repeat code and will go to great length to justify abstractions before they know if its needed. I see this with teams following iterative product development processes as well - they never want to build the 'simplest thing' first and learn. There is usually an…