This is exactly how I write code. I never engineer anything until I have to. I don't try to get rid of code duplication until it works. And I try to be as "least clever" as possible.

One of my favorite articles of all time.

It helped crystallize a number of concepts I understood but hadn’t been able to fully realize in the face of the prevailing OOP trends of the time.

It was the permission I needed to buck those trends.

Well, one might think it's not hard to predict that you will have to use buttons in the game editor more than once...

Not trying to praise OOP at all here but notice a couple of things;

- You’re not dealing with persistence. No DB, no migration headaches, no downtime requirements, etc. Constraints entirely devoid of business requirements.

- You still arrived at the same level of indirection you belabored.

- You worked off of an established project that didn’t go off on any tangents. Building bottom up, depending on how much foresight you have, easily leads to the kind of mess that you cannot semantically compress without rewriting from scratch. In many cases, especially if working on projects with multiple people, those reusable patterns will be incredibly difficult to spot due to the mess surrounding the implementations.

You’re definitely on the right track, but for one it’s not an xor choice which approach you take (semantic compression or OOP), secondly, semantic compression is not as simple as it was made out here to be, and lastly, businesses do not build bottom up.