3 ms·

Changing who to why is brilliant. That encourages investigation and understanding of the problem.

• krishnakv 14y ago
  +1 on "root cause" being the field rather than "person to blame". "person to blame" pre-supposes that the root cause is a person, which is not true in most cases. While programmers do introduce bugs due to oversight, I have seen that systemic issues (build environment doesn't allow for tests to be written, missing patches in legacy architecture, bad staffing decisions etc...) introduce a large percentage of defects, especially in larger projects. If your manager is really interested in reducing defect injection, you will want to champion root cause analysis (read up on it - Karl Wiegers and others have some some great work on this).