I think the industry’s push to design software packages as if they’re going to be reused was a mistake. This was a major selling point with technologies back in the day, such as Java. Build a software component once, then reuse it for other projects. I don’t really know what the original motivation was. Probably because people wanted to cut the cost of developers reimplementing the same thing over and over again (how many C developers does it take to implement a linked list? Well, how many C developers are currently employed?).

But this rhetoric has resulted in a high degree of complexity coming from pre-optimisation. Someone starts coding something and thinks to themselves that “hey, I may need this for something in the future. I don’t know what that thing is, but I better make sure this code is ready to support it if and when it comes.” So they generalise. They spin out interfaces and customisations to which they only have a single concrete implementation for. They start peppered their code with the logical equivalence of caveats: do this only if this implements this interface, but if it implements that interface, then do this other thing, etc. They blow out the amount of code one needs to read to understand it, with the critical path hidden, all covered by tests cases that need to be maintain to cover cases that never happen in real life.

All this present-day debt is taken out to offset the costs of an imagined future in which this component is needed and can be reused. Of course, the vast majority of the time, that future never comes, and you’re left trying to understand and support code you needlessly made more complicated by “generalising” it.

“Keep it simple, stupid” and “you ain’t gonna need it” is hard advice for a developer to follow. In a field where it’s not hard to run into someone with ego (look no further than the person writing this, dear reader) it’s can be hard for a developer to admit that the data structure or algorithm they’re working on won’t be needed for anything else. That it’s purpose is this project and this project alone. And maybe it’s premature to assume that it’s worthy of it’s own library that people will start looking at, and giving you praise for, and getting incorporated into large open-source projects that you yourself used, and being discussed by podcasters you follow, and being considered a vector for supply-chain attack by state-backed hackers because it’s an awesome library that everyone’s using.

No, put those thoughts of reuse away. Embrace the phrase “fit for purpose.” Build it specifically for the use case you need it for right now. Worry about reuse when you find that you actually do need to reuse it. Jeff Atwood in Coding Horror has this great principal known as The Rule of Three which broadly states that one shouldn’t attempt to put any effort into making something reusable until the third instance they need it. Then, and only then, can you generalise it, using the knowledge of what you need in the moment to do so well.