Eric, You are correct that it was a technical debt problem. I was replying to Ilja's post rather than the original topic.
There wasn't a broken test because technically the code was functioning (in the people patched the problem.) The normal process is to create a defect in our defect tracking system as "found during code review." So it is a type of defect. We don't write a failing test until we are ready to fix the defect though. The tests are more for regression. After we fix the defect, a test is required. In this case, it is more of a maintenance type thing and wouldn't have had a test anyway.
Understood, just wanted to clarify for other readers if you got into that situation because of a broken unit test or not.
The other really interesting part of the post from Ilja that you were replying to is:
Originally posted by Ilja Preuss: Coming back to the original topic, it's interesting to compare the question to the Lean principle of "stop the line". It states (and remember that this is how Toyota builds cars) that when there is a problem, the whole team should stop their work immediately, and together not only solve the immediate problem, but also remove the root cause of the problem.
All too often people seem to forget this aspect, which to me is oh so critical. This mentality "oh I fixed a bug; lets now make sure this entire class of bugs is accounted for as well" goes a long way toward acheiving the near zero defect rate at which some shops manage to operate. [ January 06, 2008: Message edited by: Eric Nielsen ]
author & internet detective
Originally posted by Eric Nielsen: This mentality "oh I fixed a bug; lets now make sure this entire class of bugs is accounted for as well" goes a long way toward acheiving the near zero defect rate at which some shops manage to operate.
So true. I know we aren't all the way there yet. We do this for a few things, but by no means across the board. And those few things come from having similar defects get reported a few times. We rarely think to prevent it the first time!