“Architecture is the decisions that you wish you could get right early in a project.” Ralph Johnson
It is easy to come up with rules of thumb. The author learned that he should test better and more. Maybe next time he will go overboard with testing. It is always about tradeoffs and balance. That is not helpful advice though.
My current philosophy is to have a mindset of probabilities. The optimal architecture would be obvious if you know the future. Since you cannot do that the second best thing is estimate the probability and impact and cost of all future possibilities.
Just because something will probably not happen does not mean you don’t have to mitigate it if the impact is high and the cost is low (e.g. style guidelines). Just because something will probably happen does not mean you have to mitigate it if the impact is low and the cost is high (e.g. formal methods).
In terms of probabilities a lot of architectural decisions has kind of an unknown-unknown benefits and costs unless your familiar with the tools. For our new project, we realized that configuration data in NoSQL in a AP configuration will tend of have that data corrupt for X reason. Unfortunately the configuration is embedded in relations and cannot be back-uped independently. If in the initial design of the database we had separated the config into it’s own bucket it would have huge infrastructure ramifications.
I always assume that I will get some things wrong the first time and need to fix them later but that I don’t know which things those will be. That makes me optimize for changing stuff later.