Generic Solutions at your peril

After performance, the second best way to mess up your solution design is the decision to make something Generic. Get it right and you have built a future time saver, a well understood answer to future questions. Get it wrong and you can end up with a monster.

Before you build it Generic, ask these questions. If you answer ‘No’ to any of these, maybe you better design a tight, clean, focused - for purpose implementation. - Is there already or do I absolutely know that the generic solution will be re-used and repurposed in the future? - Do I have the time and resources to invest in building it generic now in the hope of a future payoff? Remember, you need to put your best resources on this, building generic is at least twice as difficult as building a good for-purpose solution.

If you have decided to build a generic solution, keep the following in mind - Keep it simple. Please. If an implementation needs to be complicated, try to keep it in the implementation. Resist the urge to put everything in the generic solution. - Try to use interfaces. These often give you the best pattern for re-useability. - Maintain build time separation of different implementations, make sure you can discreetly recompile and re-deploy the different instances of your generic solution. - Maintain Run Time separation of different implementations - Make sure that if one goes down (or takes too long) they all dont go down (or take too long). Note that this usually implies some sort of multi-threading in your implementation.

And Last of all, these are the signs that you are getting it wrong - There is a large and complex web of static/configuration data for each instance. Most instances use only a portion of this static data and leave placeholders in the rest. - New implementations are a headache for the original designer. They either mis-use the generic solution or the new implementors pester with endless questions. - Consumers of the different implementations are involved in heavy hitting email wars with each other and are beginning to ask questions like ‘Can I prioritise my jobs so they go first’.


Michael Dausmann

Full stack developer. Agile, Data science and Machine Learning. Love learning, speaking and dad jokes. Tweets are my own.