We are working on an additional tweak to one of our features so that it will automatically add an object. I briefly met with the developer to discuss it and get a better understanding and then I put together a checklist of testing items I would be considering as part of this change. I shared this document with the developer to get his feedback and so he could see some of the things the would be considered. He put what I thought was an interesting comment on the document:
Thanks for this Dave! On second thoughts maybe defaulting is not such a trivial thing 🙂
This reveals a lot. A lot about what collaboration is good for. The developer had been thinking about how to put together code that would do what the story owner wanted, but after a short conversation and reviewing a few items in a checklist, he had a very different view of what was involved in making this happen. Our short interaction will lead to a different level of baked in quality when it comes time to actually use the code. I will still check the items on the checklist, but now the difference between what he thinks he has to do and what he actually has to do is much smaller. This means less surprises while testing this code which means less defects and less churn. At the end of the day, this means we can get this feature into shippable condition more quickly.
Sometimes it just takes a second perspective to see that the trivial thing is more complex than we thought.
offbeattesting 