Even Unintentional Pairing Detects Defects


I was sitting on the couch was organizing a database last weekend, with daughter #2 sitting next to me. I was creating a script to go through each record removing a field's contents and adding new contents to another field. Not a difficult thing to do. I created a loop, and daughter #2 said, “Hey, how does the computer know how that loop will end?” She's not a developer. I don't think she's seen the inside of a program. But she knew enough to see that I had an infinite loop.

I'm a pro at creating infinite loops. When I was developing, I would regale Mark with my infinite loops. But when I was a developer, I had a notebook in which I marked all my normal techniques for writing infinite loops. I don't write many scripts these days, so I don't track my loop tendencies. Which is why it was even more important for someone to be sitting next to me while I was working.

I took advantage of the situation, and asked her what I should do instead. She pointed out what I could do, I suggested another technique, she replied with another suggestion, and we both jointly agreed on what to do. The whole conversation took maybe 5 minutes.

The cost of the infinite loop was small, but instead of having to clean something up, I was able to write it correctly and continue with my work. It would have taken much more than 5 minutes to clean up that mistake.

Pairing while I work has been cheaper for me, in terms of preventing defects. Peer review after I write something is next, followed by formal inspection, followed by me finding my defects and fixing them. I was particularly pleased with this pair experience. Even though I didn't impress daughter #2 with my software development expertise 🙂 Better to be unimpressive than to spend more time fixing.

1 thought on “Even Unintentional Pairing Detects Defects”

  1. I’m going to generally disagree with you on this one. While it’s true that developers create defects along with defects, it’s not necessarily helpful to immediately label a perceived behavioral problem in software as a defect. This falls directly into playing the blame game and very quickly becomes political.
    Management in appalled to see 500 defects in a 6 month period; they are more understanding about 500 “trouble reports”, “malfunction reports”, “discrepancy reports”, “issues”, etc.
    Many issues reported by customers or testers (or anyone) don’t end up being in the software proper at all, they are misconfiguration, documentation shortcomings, misunderstandings, environmental, etc. But once something has been labelled a defect in a software bug tracking system (the common name for such systems — it’s also just industry parlance; it may be euphemistic but it’s not insidious), everyone tends to wash their hands of it, except the developers who are stuck with it.
    It is more helpful if it remains an “issue” and all parties help to understand its impact, source, repeatability and ultimate solution, which may or may not involve a software modification.
    Beware of inflammatory labels. Avoid the blame game and help everyone take the issues seriously.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: