There are several good points here -- particularly about the many reasons why poor code might have been written poorly, and the importance of not being smug abo

There are several good points here -- particularly about the many reasons why poor code might have been written poorly, and the importance of not being smug about it. I don't think there's much value in blaming authors. But just like when we have an outage, we don't just repair the problem, but we try to fix the conditions that allowed it to happen, I think when we find bad code (and especially broken code), it's valuable to understand what practices led to that and try to improve them. That means pointing out when code was never tested or when obvious edge cases were missed -- or any of the explanations listed in the post. Sometimes, the lessons are deep and important (like the relative value placed by the team on developer's time vs. QA's time or Ops's time).