On Building Software

Avoiding Fancy Abstractions

I avoid fancy abstractions until I need it and I find that I rarely do. DoneDone’s codebase almost never uses interfaces and even subclassing is rare.

The kind of code that I like to write is the one that is most easy to read and to dive into at any point. There’s a balance here certainly. The easiest kind of code you could come up with might be a laundry list of booleans like isTwoPlusThreeEqualToFive or isUsersPasswordEqualToPassword1 but it would be painful to write anything useful with this approach.

On the complete opposite end of the spectrum is a codebase littered with interfaces, generics, multilevel inheritance and any other assortment of concepts that are meant to widen the net of a codebase’s extensibility. It feels professional.

Well considered.
Sophisticated.
Elegant.

Because it probably is.

When the time comes to add something new, a fanci-fied codebase might be able to support that new thing more easily than one that had more rigid edges and pathways. Except for the fact that it will be a human being who will need to know how to do this correctly.

And a codebase written in a way to shield code from large changes in the future will almost always make code less obvious and understandable to the human now.

The painful part of adding more code is not the amount of code or the amount of changes or the amount of touchpoints. It is someone’s confidence in understanding how all of the existing code relates to the new code. And fancy abstractions are a way to guarantee less of this confidence.

When I write code, my goal is not to shield code from large changes in the future. It is to make code as obvious and understandable as possible now. Because the former is not the harder task for humans.

The latter is.