We say a software architecture is good when the entire program is crafted in anticipation of a CHANGE, meaning the measure of a design is how easily it accommodates changes.
Decoupling is a key in a good design because it minimizes the amount of knowledge needed before making a change in the code. On the other hand, there's a cost: we should not over-do it as that would end up being a bad design and takes more time to find a piece of code that actually does something.
Writing throw away code for the purpose of prototyping is completely legit. But make sure it will actually be thrown away.
Striking a balance:
The quickest code to write is rarely the quickest code to run.
Highly optimized code is very difficult to change.
Balance is a trade-off, there is no right answer.
Simplicity:
Write simple code but make it general in the sense that it covers a wide space of use cases of the problem.
Abstraction and decoupling makes evolving code easy and fast, but don't waste time doing them unless it's necessary.
Always think about performance during the development cycle, but delay the low-level optimizations.
Don't waste time making throw-away code pretty.
Reading this book is fun and very educating, the writer has a unique style and of course is relating to games which makes it even more fun. I think I'll adopt his opinions regarding good architecture, I'm convinced.
Now that I know what is a good software architecture and what is good in the bad ones, I'm excited to continue reading the book to learn some design patterns and see how professionals implement and utilize them.