REST

I recently learned how REST is part of good design.
Representational State Transfer means that each module can derive it's state from the messages it receives.  It doesn't maintain state; state is part of the message.  So the nodes on a FSM send state along the edges.
In general: a good object is self contained,  it won't crash because it's state is violated by events that are unanticipated.

Tentacle design

What's not rocket science is the philosophy of the design, and good design.
But that's not the design itself.  The specific design is closer to rocket science.
Philosophy:
Tentacular design:
Every subsystem has some dependencies on other systems.
Any dependencies:
Common Macros, variables, common data, common timing, methods, subroutines, events that influence,
waiting for thread loops (WFMO is wait for multiple object), results, etc.
In short, probes and sensors that cause one subsystem to malfunction based on an event in another module.
Including a bug in another module.
These are all tentacles, reaching into other systems.
Some people seem to have a mistaken belief that "integrated design" is good.
This is false.  Good modular design means creating classes or any modules, that can exist independently of other modules.
That have the FEWEST tentacles as possible.
In C++ or any language.
Very very simple.

Test for Good Software Design (C++ precompiled headers are an excuse)

Here is a great and simple test for good C++ design.
If you have to add a header file for a new class or structure to one module, does it cause many other unrelated C++ files to be recompiled?
You had to add the header include to another header that is included by lots of .cpp files.
Precompiled headers are used as an excuse for bad design.

Good Software Design

1) Use standard C++ code, as few Macros and Globals as possible.
2) As few dependencies between modules as possible. Modules should be as self contained as possible.  Less dependencies on the platform the better, depend on standard C++ only as much as possible.

Conventions, Change, Uniformity, Potential

When I look at software I see potential for change, for improvement, (even if just mine, inside of me, my own understanding).
Stifling creativity.  Uniformity makes it easier to see (transparent) but also opaque to potential to change.
Conventions create the illusion of solidity but the solidity is apparent, but not real, to it's potential for reinterpretation and redesign.
Uniformity and conventionality.
I'm not stubborn, perhaps ignorant.  But the idea that (they) cannot go in and fix my code when (they) have a better idea to demonstrate what (they) feel is needed, or right, is a little odd to me, and hard to accept, and - what's the word, humiliating? hyper pedagogical? self important?
Perhaps (they) are just trying to be pedagogical and I over-react.
I can get emotional sometimes, that's another of my faults, (but even that's open to interpretation).

On Optimization

People seem to ignore the effects of age and chance.
Something might not need optimization but might need it in the future when the system is more complete, has more users, or has more applications. so in this case, it may a good idea to optimize (up front).
Secondly, there is a lot of code that is slow but not slow enough for humans to feel it positively but it causes sluggishness at the borders of perception.  Optimize if possible and/or easy, and/or to add polish,  to improve the customer experience,  even if the improvement is not obvious.
Especially if the SW has a long life ahead of it.  An obvious example would be the fidelity of music.
To assert that only the highest fidelity of audio that is necessary, is desired, is false.
Those blanket "don't optimize don't do this or that" are not universal truths.

Good software design and simplistic ideas about life.

Software and Life
When software, or life, has unforseen difficulties, breakage, or simply does not work in unexpected situations or events, is this a problem or an opportunity?  Do you believe that a person can be designed not to experience troubles when random difficulties emerge in life?  No... the way to do that, is to allow for changes, to test oddball situations.  Not to try to make things perfect the first time.
Good software has been stressed and tested in real-life situations, allowed to break, analyzed, and improved.
If the user does something wrong, is it an issue, if the software crashes or breaks, because of the user's error?
Some developers think it's not.  However, the best software is written to handle breakage, errors, the unexpected, and oddball cases.
Do car companies design cars to work in ideal conditions? No. They break cars to see what happens, put them under stress, and make cars that can last through problems in the environment and some abuse.  The best cars can handle a lot of abuse.
In our lives, when errors occur, do we learn and survive, or simply break and die?
There are two schools in making software: simplistic, and real.
A simplistic school maintains that you design software carefully, so that when it is implemented, it works.
The problem is, no amount of planning can forsee the odd cases.  It is necessary to break software, to use it incorrectly, to write code that handles problems of usage and abuse.
The philosophy that problems of usage don't matter, is wrong.
The good philosophy is that we plan to break.  We anticipate changes.  Software adapts intelligently,  and gets better than it would be if not used incorrectly and analyzed.
Changes can break things, but breakage solves design problem that would not be seen otherwise.
Look at living things.  They evolve because of those 'survival' mechanisms that are so cruel, and end up producing the most nearly perfect biological creatures you can possibly imagine.