because generalization
Part of a series of posts that discuss justifications for spending more time on a specific piece of code, rather than continuing onward.
The generalization justification for polishing code goes something like the quote below. Part of what makes the tendency toward generalization so insidious is the multiple levels of generalization you can employ before stopping.
I see similarities between this code, and code we’re written in the past. If we generalize it we can save a lot of time in the future. I can also imagine so many ways in which we could reuse this! In fact, I’ll bet if we made this a product we could make loads of money!
One of the best, and among my favorite long-form articles on the harms of software design taken too far is the imperial clothing crisis by Kevlin Henney (for the purpose of this article, feel free to skip down to the “simplicity before generality” section). I use this article all the time to push back against well-meaning, but harmful suggestions to generalize some bit of code, rather than shipping something that is good enough.
When does generalization harm us?
As soon as we go beyond the amount of abstraction necessary for the problem at hand we are shockingly likely to fall into the generalization trap almost immediately. Truly useful generalizations or abstractions are incredibly powerful, which is why so many people pursue them. But they are also so exceedingly rare as to be not worth pursuing until literally nothing else will work.
If you think I’m absolutely nuts on this topic, then consider how software would look if useful generalization really were so easy to stumble upon that it was the norm. The software industry would have long ago become one vertically integrated whole built upon ever-increasing amounts of abstraction, which it is not.
There is actually so much differentiation in the needs of software systems that it supports an entire industry of programmers constantly churning away at novel solutions. If it were not so, then the world wouldn’t need so many programmers.
When is generalization helpful?
Only at one of two extremes:
- A problem is so simple that it becomes the obvious way to do things — these can easily be built by solo programmers, and often come in the form of zero-dependency libraries or modules
- A problem is so difficult that collaboration rather than innovation is the only possible path to success
The vast majority of software falls into neither of these two categories. This is why there so many programmers in the world — because the majority of code needs to be customized in some manner.
