[proc0]

This is in context of a one person team. The next advice makes this evident:

> Remember that you can always rewrite any part of your game/engine later.

This isn't the case in medium to large organizations. Usually you will just move on and rarely have the time to revisit something. This is unfortunate of course, but it means you need to build things properly the first time around and make sure it won't have a chance to create bugs or side effects. I have worked in too many codebases were people feel the need to rush new features, and then it creates a minefield of a codebase where you have to manually check every feature and have the entire application in context when changing something small.

[_nist]

I agree with this. In a large organization, if you have risen to a level where you are being relied upon at a regular intervals, it is imperative that you have a well architected solution that you can readily change and this is where you separate your program from spaghetti code to something useful. Sure, its nice to write unmaintainable junk when toying around, but I to have seen too many codebases where people were just throwing features in without thought and it causes the program to become way too constrained to only a specific problem domain and it becomes inflexible for solving new problems (to the point you have to re-write nearly everything from scratch).

[jaggederest]

The contrast to this is to put in tickets specifically for refactoring and reorganization, but I've rarely seen that work since they often don't have any sweetener included to encourage e.g. product organization to sign off on the work.

[_nist]

Yeah, it's a shame, I often have to do this type of crap in my off time. However, having a well architected app significantly reduces these types of massive undertakings. Doing it right the first time has its advantages. Then again, weighing it against delivering early and other important aspects has its merit too. It's just a double edged sword unfortunately that you often have to walk in this industry.

[stouset]

Most importantly, you need to get interfaces right. The right interface that allows the caller to express their underlying intent allows you to rewrite bits of the implementation as-needed without forcing a rewrite from your downstream consumers.

[exe34]

> it means you need to build things properly the first time around and make sure it won't have a chance to create bugs or side effects. I

yes! and this means you need to know everything about what you're building upfront! so now you have to do waterfall, but hide all the actual effort and pretend you're just figuring it out in the moment because agile.

[proc0]

I agree, and would add that agile is bad because it's used to iterate along the product vertical, so first create an MVP, then add features. Instead it could be used to iterate from a technical standpoint, first adding the helper functions, then the interfaces, then some of the core functionality.. but the problem there is that most orgs prefer immediate "business value" at the cost of long term good engineering. In some cases, when the application is meant to be short-lived this makes sense, but more often than not I've seen teams suffer from this approach, not realizing they have been digging their own hole for years.

[exe34]

> so first create an MVP, then add features.

It seems to guarantee technical debt starts to build as soon as possible and as fast as possible!

(I.e. I'm referring to agile as it is practised, not the true scotsman's agile. We apply the same rigour towards socialism.)

[eliasdaler]

I agree. I should probably clarify that in the article. It’s much easier to write “throwaway” code when you’re working alone and when you’re doing it just for fun. This advice was probably aimed at people who tend to overthink things in these kinds of situations and spend years implementing things in the “right” way, which tends to slow them down considerably instead.

[ngcc_hk]

I guess what you said is right - the starting code and the later refactored code for reuse is and should be different. You experiment a lot …

Anyway after reading I still struggle. All these discussion is about game. I am more on simulation like Game Of life but in 3d (2d done using sdl and except iOS-mixer, one code base can run on most platform I care about). And possibly VR. May be back to unity and … learn so much using c/c++ using sdl especially just pass grenderer and gwindow around and just use function pointer. I guess 3d is out of reach based on reading your article. Very enjoyable reading nevertheless.

[HelloNurse]

A large organization is likely to have both a separation between experiments and the "actual" game engine, containing the churn of throwaway code in order to build on good foundation, and significant experience and reuse from their previous game engine, constraining (possibly for the worse) the experiments and rewrites.

[ngcc_hk]

My reading is slightly different. It is not about a 1p team, but about a 1p team just starting and learning. Once finish learning you still have to go back and refactor for future maintenance. He has to reuse these codes as part of an engine, just like a larger team.