Nearly every organization in the world is suffering from the generic problem. The generic problem is an elusive beast, one that takes up an enormous amount of time and money out of human society.

The generic problem leads police departments to dump hundreds of thousands of dollars into 25 year old software systems. It forces every banks to continue to run on COBOL in 2018 and salesforce to build the tallest building in the middle of SF.

The generic problem is a collection of issues that are too generic or obscure to deserve a specific solution yet are somehow only truely solvable with one.

For example, let's say you're a political party in a small county in a rural state. You have a rough list of folks that you'd like to keep track of, some that you support for various positions, some that are currently elected, some that support your competing party, some that haven't decided if they'll run for anything at all.

In the past, you fix this with an excel spreadsheet with about 800 or so rows.

Your list isn't big enough to warrant hiring a software engineer, so any data clean up needs to be done manually or via other generic tools.

But as the days go on and your list grows larger, you start to realize that you don't actually have all the information you need. You'd like to track offices and who holds them over time.

In a specific solution, you might use a database with a many-to-many relationship. One table for people, one table for positions and another for assignments with keys relating to rows in people and positions.

At this point, you've out grown your generic solution (excel) but do the small nature of your problem, it also doesn't seem to warrant a specific solution. So instead, you duplicate information in your sheet and you cloodge your way to a solution. Or you ignore the problem and hope you can keep these things in your head.

You've effectively created non-technical debt that slows you down. But it's better than having to drop 100k on an engineer for an only slightly improved solution.