More thoughts on defects in an agile process

There are a lot of things to like about the Lean movement and the Toyota production system, but I worry that blanket application of their principles to software development may be misguided. Just as with other metaphors used to build a mental model, the metaphor of software development as a factory has big holes in it.

This becomes particularly apparent when considering the concept of defects. In a factory the job is to produce output in large quantities, all of which is consistent with an initial design. From this premise it is easy to understand that any difference from the initial archetype is a defect, which means that the factory process is not working correctly and needs to be fixed.

In software development, the job is not to produce multiple identical things, but to produce new things which did not exist before. From this premise it follows that there is no definitive archetype against which to measure differences. Sure, producing identical copies of software for sale or distribution is like a factory, but typically that process is almost trivial, requiring not much more than a “copy” command.

When developing software we sometimes find ourselves in the uncomfortable situation of not knowing whether something is a defect or not. All we know is that it is different from some expectation, but any particular difference may be a defect or it may be an improvement.

Testing: What is a defect? at Mark Needham

In an agile process, what is a defect?

Can anyone point me at any resources on Toyota’s approach to product development, rather than the familiar material on their approach to factory production?