Bug Management: Stop the line
In a previous post, I was proposing to stop the line when discovering a defect that is clearly worth fixing.
Stop the line is an expression coming from the Toyota production system where, because there is not inventory to use as buffer, a defective piece results in an interruption of the production line. The advantage is that it forces problems resolution. In the case of defect management this means that instead of recording a defect we know we will have to spend time on, and store that time in our inventory of bugs to fix, we do it right then and there.
This obviously assumes that the team can make a resolute and quick decision of what needs to be fixed or not. It also means that it is that much less effort spent into tracking the defect’s life from discovery to investigation to resolution to verification. There is no need to record that defect as the record will become obsolete very quickly. This is already what happens for severe defects found in a production environment. An extra benefit happens when the defect can be directly traced to the originator (which requires a fast feedback loop) as the originator (rather than another person) will have to sink the time to fix the defect, very visibly so, introducing a very strong incentive to deliver quality work all the time.
Adopting this attitude also means that defects on record are the ones which may be fixed in the future. No need to really prioritise them anymore as if the defect was to become more important it would be re-raised in a stop the line manner. Defects on records would then become a sign of “code smells” or highlight areas that may need significant re-factoring that the team can take on at a convenient time.
When playing with this idea after David Anderson’s talk at the Bay APLN and pondering the Iron Chef presentation that happened there too, someone objected that there are cases when defects would require a serious rework and take a lot of time and should therefore be tracked. And I agree. However, either that rework should already be counted in the defect originator’s work and then it is already tracked or it is likely the defects were there for a long time but were never discovered before because the function was not used/tested. In this later case, it should be considered as rework to upgrade the existing functions and be prioritised and tracked with the rest of the work. It may be that it becomes client valued work (pretty similar in my mind to the upgrade work you have to do in a house when the construction code changes).
What do you think of the stop the line philosophy ? Have you practised it ? Did it work for you ? How did the process look like ?
