> "where you tracked what sort of bugs were caused by what sort of constructs, and design your program in such a way to minimize their chance of being introduce

> "where you tracked what sort of bugs were caused by what sort of constructs, and design your program in such a way to minimize their chance of being introduced. I've never heard of anyone except Dan Bernstein actually doing anything approximating this" Not sure if I completely understand but here[1] is a talk by Jules May called "If considered harmful: How to eradicate 95% of all your bugs in one simple step" where he discusses that they analyzed what was causing a lot of bugs in their programs, and found it was code which keeps state synchronised using `if` in far distant places in the codebase, many places with "if (stateFlag) {}" which then gradually fell out of sync with each other as people changed some but not all of them. By redesigning the programs so that instead of call points dotted around the codebase all saying `if (condition) { function1() } else { function2() }` they all say `obj.doWork()` any the condition checking code only exists in one place inside the class definition, the talk title claims they removed 95% of bugs in their codebase. Inside the talk he spends all the time explaining the idea and doesn't actually talk about the effect it had on their bug tracker database, bugs encountered, etc. which is a bit of a shame. Of course, the comments are suitably sneery for a programming talk: "having double checking being your main source of bugs means that you really try your best to write bad code. The whole talk boils down to: double checking conditions is bad and we found it 20 years after everybody else." - even if you agree with that, the analysis of their bug tracker to find what was causing most bugs and redesigning how they code based on that, appears to be an example of what you describe. [1] https://www.youtube.com/watch?v=z43bmaMwagI https://www.youtube.com/watch?v=z43bmaMwagI