[fastbeef]

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.

[herval]

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?

[logicallee]

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."

[fastbeef]

You don't know how close you are...

[partisan]

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.

[WalterBright]

One pattern is a high tolerance for "good enough" results or even wrong results, as such errors don't particularly matter in a game.