One of the things that we have to understand about software is that software is a matter of making and recording decisions -- from what kind of a variable to use and how to name it, to how to use classes and libraries, to technical details about how to lay out code for the optimizer/pipeline/etc, to how to lay out data for map/reduce queries, to how to present and collect data from humans, to the ever-important issues of prioritizing and slicing features to ensure we don't build unwanted code.
This is difficult because all the systems we work in are bigger than our own craniums.
All defects in software are decision-making defects, which means that the single greatest thing we can do to avoid defects is to create the conditions for making better decisions. Those conditions seem to be feedback, safety, focus on learning, short reach, and ever-simpler design. I applaud your efforts to document the lattermost.
These are good steps to take, and I endorse the article (with of course some additional notes about pairing and test-first), but I would like to amplify that no amount of mechanical design will ever be enough. We have to change the human system so that learning is easy and fast, and failure is local and safe, feedback is immediate, and the inject-detect-correct period is as short as humans + machines can make it.