Avoid premature abstractions

Stop me if you’ve heard this before:

You may have had a few ideas on creating “reusable” components to “save labor” and “deliver quickly.” Inspired, you decided to set aside some time to build your idea, and you were able to build a library that resembles the first iteration of your vision. You then proceeded to “encourage” your team members to adopt this new “framework,” which they have started to adopt in their new projects. Unfortunately, other concerns beckoned, and you had to pause development and work on something else.

Meanwhile, your teammates have started to prepare feedback on this new library, but no guidance was forthcoming. Realizing they were on their own with regards to using this new library “to deliver quickly,” they proceeded to put workarounds to get the new library to work the way it needs to in the real world.

The new library aimed to “save labor” and “deliver quickly” ended up costing time in terms of training and workarounds (and you will hear comments like “it sounded like a good idea at the time”).

Remember: just because you can, doesn’t mean you should.