I took me many years, but I’ve finally accepted the rule of three; I’ve burnt myself repeatedly on my poorly thought-out abstractions that support a single actual use case.
This is exactly how I work, and I went through a similar process to the article writer in coming to learn that premature abstraction fails for the same reasons premature optimisation does: before you have enough data to analyse (in the form of code that executes slowly or obvious refactoring candidates), you’re working blind, and it’s sheer luck if what you decided to optimise or abstract would’ve been a hot path or good model. Having only two similar things isn’t enough to predict what the “pivot points” of an abstraction over them and future things might be.
I took me many years, but I’ve finally accepted the rule of three; I’ve burnt myself repeatedly on my poorly thought-out abstractions that support a single actual use case.
This is exactly how I work, and I went through a similar process to the article writer in coming to learn that premature abstraction fails for the same reasons premature optimisation does: before you have enough data to analyse (in the form of code that executes slowly or obvious refactoring candidates), you’re working blind, and it’s sheer luck if what you decided to optimise or abstract would’ve been a hot path or good model. Having only two similar things isn’t enough to predict what the “pivot points” of an abstraction over them and future things might be.