202204262114 Write code that's easy to delete, not extend

Instead of building re-usable software we should try to build disposable software.¹

Writing code comes at the cost of maintaining and changing that code. After all, 202204272219 The fastest code is no code and if we don’t have any code to begin with, we don’t have to maintain, extend, or delete code. The actual cost of maintaining that code can be astronomical (202204031033 Abstractions and future-coding are actively harmful)

We should be striving to minimize our code which includes deleting code that is no longer serving its purpose or has had so many requirement changes that it’s no longer recognizable as what it set out to be.

We should be writing code that’s disposable and cheap to replace. It’s easier to replace code than sort through dependencies and modify systems.

It’s usually easier to delete one big mess of code than to try and delete multiple smaller interleaved mistakes. It’s especially true that we don’t know how to split our code before building it and that it’s easier to deploy one mistake than 20 smaller ones (202204272239 Monorepos make all the wrong trade offs).

In order to write easily disposable code, we need to repeat ourselves over adding dependencies (202204262054 Prefer duplication over the wrong abstraction). We need to layer our code so that APIs don’t cause sweeping changes (202204272256 Create internal APIs on top of dependencies). We need to isolate hard to write or likely to change (202204272307 Code that changes together should live together) parts from the rest of the code and each other. We need to allow some changes at runtime and swappable implementations. We need to be able to write new code next to old code without modifying it (202204272242 Open-closed).

Most importantly, We need to write less code to begin with.

We are not building modules around being able to re-use them, but being able to change them.¹

The 202204291512 Single responsibility principle says “each module should handle only one thing”, but it’s much more important that we can say “each hard thing is handled by only one module”.

Error handling and recovery are best done at the outer edges of your application.