Rule of three

Of all the horrific code I have written, by far, the most harmful and destructive have involved too early abstraction. Everyone knows the issues stemming from the wrong abstraction. Even copy-paste code would have been a better choice than creating some seemingly fancy, say, adapter pattern implementation. To be honest, I think copy-paste has a worse reputation than it should.

A given project might have started with best practices, module structure, libraries of a prior project/16k star primer. That can be good! Some best practices naturally transcend projects. We should bring in the lessons learned but the timing matters. Upon a closer look, the project might indeed have agreeable abstractions. Still, those could be hollow and bring only extra LOCs and solve the issues faced in the previous projects, which have never occurred in the current one.

Upon recently starting two soon-to-be large projects, I learned to leave some wisdom from previous lives behind. While deep in the coding zen, I'll still predict that: "Hey, I need this and that kind of a library," or "Hey, let's start building a complete component library." I need to keep telling myself, you aren't gonna need that! 

The disadvantage of this kind of approach is that the code will be a mess - for a while. As the codebase grows more involved, there will be massive refactorings touching tens or hundreds of files breaking dozens of tests. When the team sees enough violations of the rule of three's, some discipline is needed to pick up that design pattern or find a fitting library to address the outgrown cognitive load.