Growing object-oriented software vs. what I would do

This point hits hard.

Managing "live" scattered state that is gonna go away when the program dies is hard in itself. But as soon as you have to persist it or do anything fancy with it, you pretty much have to change the whole approach of your app. This is why it's always a good idea to start with established frameworks that handle persistence if you're ever gonna need it. Bolting-on is just too hard.

It also reminds me of my first job, in a Desktop app. State became so complex that to apply a "global change", like currency or language, it was required to close the app and open again. It was something very common, seeing how many apps required such things.

In the middle of my career I also worked in a very large video game. The higher ups wanted to change how "game saving" worked and instead of having to serialise just the basic stuff (health, lives, level) we needed to change it to serialise the whole game state including enemy positions and actions. It was the biggest change we did and we ended up having to add lots of boilerplate because of the scattered state. IMO, ECS was a very interesting development purely because now state is not encapsulated anymore, making serialisation completely separate from everything else.

Curiously, as much as modern frontend programming is maligned, such issues are easier to solve with central state management libraries like Redux.

Another similar issue that I see a lot in both Java and C++ codebases is "premature wrapping" of foreign APIs. Basically when building a program that has to consume a certain API that is somewhat incompatible, every single concept of this API is wrapped in a separate class before any planning, to the point each one-line procedure call turns into a 20 line class.

Of course, after the wrapper is written, the program still needs higher lever abstractions that use those wrappers. But since zero planning went into the design, now you need exactly the same call order as before, however instead of an ugly (but simple) procedure call, you have a class wrapping it, and to understand a simple workflow you have to go trough at least two layers of classes.

Not only is that not the secret sauce, an OOP program with almost nothing but methods that return nothing (i.e. have some effect without reporting a result), is a giant red idiot flag.

1. not all software is about pushing and pulling to/from a database; if yours isn't, be sure you understand why that's the case.

2. "backends" (not "web backends", but the more general "where the mechanisms are") should know nothing about "frontends" (again, not web, but the more general "user interface of some kind"). This is really just MVC in its most basic sense. One good way I've found to think about this is to assume that there's always at least two UIs running simultaneously. Make sure this can work.

3. if your program has a user interface, everything the user can do without further interaction should be represented by a closure that can be invoked from anywhere (but always in the correct thread).

4. single-threaded GUI code seems like a limitation but in most projects, it's the right choice. By all means use helper threads when needed, but never allow them to use any API that's part of your GUI toolkit. Knowing that your GUI code is ALWAYS serialized is a huge conceptual assist when reasoning about behavior.

5. access to an excellent cross-thread message queueing system is likely to be a must if your software uses threads. This should include a way for one thread to cause arbitrary code execution in another thread.

6. direct memory access for the UI is nice from a programming perspective (that is: just directly call methods of backend objects), but can erode the wall of separation between the UIs and the backend.

7. lack of direct memory access for the UI(s) can significantly impede performance, but enforces a conceptual clarity that can be valuable.

8. when notifying the View(s) about changes in the Model(s), there's a tradeoff between fine-grained notifications ("frob.bar.baz.foo just changed") and high-level notifications ("something about frob just changed"). Finding the sweet spot between these two can be a challenge across the life of a long-lived piece of software.

9. lifetime management will never be trivial. Accept it, and move on to thinking about how it is going to work even if it is not trivial.

10. try to refer to as many things as possible indirectly. if something has a color, don't make it's state refer to the color, but the name or ID of the color. do not over-use this pattern when performance matters, but also do not over-estimate your ability to understand when performance matters.