DesignLog case 1:
"You're delaying my project!"

I was asked to teach Document Inspections to a group of developers. I gave a short introduction and then we did a baseline review. After all, most people do reviews, don't they?

We selected a design document for some firmware datalog functionality in a controller, took one page from the document, and made 20 copies of that page for everyone to review. They started reviewing and after some 10 minutes everyone seemed ready.
I asked about the issues found. Hardly any. Perhaps a typo or two.

Then I introduced a Rule ("Rules are the Law of the Document"): "If we don't know the requirement of this design, how do we know that the design does what it should do and does not what it should not do?" I asked them to review once more.

After a short while, everyone's paper was full of remarks: This I cannot judge, that I cannot judge, because I don't know what was required and why this is the best solution. With the review they had found out themselves that there was a lack of knowledge what 'design' actually means. If I would have told them, they wouldn't have accepted it. Now they showed it to themselves. This is an interesting alternative use of the Inspection technique!

We suggested the designer to make a DesignLog. Not to write even one line of code until the DesignLog was reviewed and found OK. It took some time until the author understood how to make the DesignLog, but it led to an interesting conclusion: He decided not to implement the functionality in the controller firmware, because of some intricacies which could much better be solved in the PC software at the other side of the network, when analysing the datalog data. Imagine what would have happened if he had started coding already. Getting deeper and deeper into trouble, not wanting to stop, because having spent already so much time on coding.

First he had complained that I was delaying his project because he wasn't allowed to start coding. Later he said: Thank you, you saved my project!