Having never used it, I find your explanation logical. This sounds like it would be a useful tool for parallel testing. However, I would contest your point that "the alternative to not checking in code with bugs is writing perfect code every time". I would argue that the best alternative to checking in code with bugs is to test it on all available test cases and possibly new ones *before* it is checked in. This won't be perfect, but it will be much less of a hassle for other members of the team. I doubt the developer is really bad at writing and testing code, but I don't think his style of self-deprecation did him any favors there.