This is what people mean when they talk about "technical debt". Many of us have realized that when mistakes are not fixed early, we end up doing 10x, 20x, and e

This is what people mean when they talk about "technical debt". Many of us have realized that when mistakes are not fixed early, we end up doing 10x, 20x, and even 200x the amount of work in dealing with the consequences of those mistakes. In Software Development good tools like an IDE with static code analysis and good practices like unit testing + integration testing + functional testing + automated acceptance tests help us to avoid that 200x downside. DevOps is not all software development, but part of it is, and so it should respond in the same way to good tools, and good test practices. For the rest of it, there are lots of old practices that do make a difference such as having regular backups of everything, having live-live standby servers, hiring a DBA to clean up the mess in your data models, NEVER patching the database except using code that has been unit tested and which generates a script to undo everything that it has patched along with a hash check of the database to guarantee that the undo step worked. And so on. Maybe the cute moniker "O-ring economics" will help to explain it to management types better but the jury is still out on that, IMHO. But what manager would NOT want everybody to work as a team, to learn from their mistakes, and to constantly up their game, as a team? Call it Agile or call it something else, but this is what is proven over the last 70 years or so (perhaps even longer).