Post

I feel like frameworks are only useful once you need to abstract things for other people to use. Internally it's almost never useful to add this layer of abstraction. But when you want to create something that others can use, then it can become really helpful.

I sometimes refactor small parts of jam games into reusable frameworks if there's interest from other devs. The purpose then becomes to make it independent of the actual project it was made for. But that's also exactly why I wouldn't create a framework when it's only used internally in one project.

Often it's even more helpful, to others and, more importantly, your future self, to just have reusable self-contained components which you can quickly copy and adapt between projects, I find.

I have very specific cases for the word "framework," usually with design systems not made from scratch (Carbon, MUI, etc), and any process where I don't want to focus on methodology. "Framework" is sort of a catch-all when I'm trying to be agnostic regarding tools and services.

Former architect of very large, complex systems here (with patents to prove it): you really need to specify the realm you're talking about. Games are small, self-contained, iterate fast and don't have to be maintained, so sure. My systems? Your opinion is invalid to a fire-that-guy level.

> "Games are small, self-containted, iterate fast, and don't have to be maintained, so sure" I strongly urge you to read up games such as Fortnite and World of Warcraft, with millions of users and decades of live development, as they are 10x more complex than most backend corporate B2B architecture

From a 'fire-that-guy level' the statement you made would have you fired into the sun if you said it out loud to any game developer.

Like building a framework so that players can fire off 5 abilities at the same time, and the game designers are still iterating what the gameplay will even look like! How much time are you wasting? Or making an entire animation system for feet on staircases: Will the game even have many staircases?

This is one of the two all-time tradeoffs in engineering: Doing something big now to POTENTIALLY save later, or doing it quick now. With the other one being flexibility vs simplicity.

YAGNI vs. YMGNI

Instead, build an initial version of something, with throwaway code, see if it's any good with users, adjust it, do that a few times, and then when users are happy, and you think it'll be used many times in many places, you make a framework for re-use. But not any moment sooner!

This implies that companies generally have management that understands the importance of throwing away prototypes to make 'the real thing'. "But we can see the pixels on screen doing the thing we want; why throw it away? Just iterate on that and ship it!"

The exception is if you're using an engine or API that has an existing framework, such as GAS in Unreal. Please use that framework, and do not try to reinvent it! Make it do the work for you, and stick to it from the start, as it will be intertwined in all the other already existing systems.