Without going into details, the product was started 10 years ago by one of the programmers whom I suspect wanted to be a game developer, so the product is filled with gamedev patterns and due to a tech choice it's not possible to migrate to a modern architecture without rewriting the whole thing.
Would be funny to see, say, an enterprise software filled with gamedev patterns. Would you care to elaborate on any of it? What kind of patterns were specifically glaring/out of place?
you're right, that does sound pretty funny. "the database backend was actually on the GPU - it was all in openGL, just in case. We were Mobile first, too - got 1 GFLops on iOS. Unfortunately we sold irrigation controllers for large farms."
I can imagine someone using component entity systems where they don't exactly make sense. I worked with a manager who considered using it, under a different name and not tied to game dev, in a very LOB application because he thought the requirements were changing too rapidly to manage in a traditional way.
Another possible artifact would be a custom memory allocator or patterns around memory or object management that make no sense in an application that isn't memory constrained or allocating large amounts of objects in such a way that is causing a bottleneck.
Maybe the programmer was unrolling loops in the name of maximizing performance where it wasn't actually required.
I am sure there are plenty of other signs a game dev hopeful would leave in a code base if left unchecked.