Writing code you can delete

Programmers are usually taught to write code that will survive: reusable components, flexible abstractions and systems prepared for every imaginable future requirement. But what if trying to make code immortal is precisely what makes it difficult to maintain?

The author known as tef, writing on the blog Programming is Terrible, proposes a more useful goal:

“Write code that is easy to delete, not easy to extend.”

Every new line creates a future obligation. Someone will have to understand it, test it, update it and check what else depends on it. Reusable code may reduce duplication, but premature reuse can connect unrelated parts of a system. Once several features depend on the same abstraction, changing or removing it becomes surprisingly expensive.

This leads to a counterintuitive conclusion: a little duplication can sometimes be safer than an elegant abstraction. Copying a small fragment of code two or three times keeps those implementations independent. Only after their real similarities become visible do we know what should be extracted into a shared function. Abstraction created from evidence is usually more reliable than abstraction created from prediction.

The same principle applies to architecture. Frequently changing business logic should be separated from stable infrastructure. External libraries can be placed behind small interfaces, experimental features can be isolated, and difficult decisions can be confined to individual modules. The objective is not perfect modularity. It is the freedom to change one part without rebuilding everything around it.

The surprising measure of good code is therefore not how impressive it looks or how many hypothetical uses it supports. It is how little resistance it creates when requirements change.

Software rarely fails because programmers cannot add another feature. It becomes painful when nobody can safely remove the old ones.

Source

— tef, Programming is Terrible

Sources:

— tef