DesignLog case 2:"We don't have time! - We've only 7 days left to deliver!"
One day we were having a chat after a long day of finding out the real goal of a certain project.
James came in with Louise and said:
Niels, this is Louise.
Louise, this is Niels, who taught me about DesignLogging. Tell what happened.
Louise:
We had only 7 days to finish some software.
We were working hard: coding, testing, coding, testing.
James said we should stop coding and go back to the design.
"We don't have time! - We have to finish the code! - We've only 7 days left to deliver!"
James insisted.
We designed, found the problem, corrected it, cleaned up the mess. Done in less than 7 days. Thank you!
It's always nice to experience that the techniques that worked for me, and for many others in the past, still work today. Many old techniques never get out of date.
We see, however, that it's not so easy to convince people to do something that seems
counter-intuitive: going back to the design rather than grinding on in code, leaving a lot of dangerous scars in the process. Delivering quality often needs counter-intuitive measures.
Later, James provided even more intriguing details:
- There were two features required for a release, one of which was on the critical path and placed the delivery at risk
- I saw an "opportunity" for a Design - "prevention, rather than fixing" and also an opportunity to encourage documentation (as you describe it in communication)
- Because Louise struggled a bit with the design (not many people in software have been educated in how to design) we Timeboxed the initial draft
- I emailed it to two colleagues to review: "Please review, assuming you will code-review the implementation, and based on this DesignLog you should know what the implementation you'd code-review will be"
- Louise emailed me in a panic that if she knew it would be reviewed, she would have written something different. I said - "no, do nothing yet - let's do the review first, and then update with your new understanding and feedback. Reason: next draft will be better."
- For the next review, another colleague who was not previously available was invited. At a meeting where I expected the DesignLog to be approved with minor modifications, and to get estimates for the work involved, the Design was totally reworked
- We agreed the new Design was better than the original ideas
- Actually, two features were delivered and deployed
- The one that was designed, reviewed, coded, and code-reviewed, had no issues after deployment
- Another one, which was done in the ‘traditional’ way, was the source of quite a few defects
- In summary, this success has proved instrumental in buy-in for DesignLogs, which are now embedded in the development process
Conclusion:
Design - Review (repeat as needed) - Code - Review (repeat as needed) - Testing doesn't find issues - User doesn't find issues. A great technique to move towards Zero Defects!
DesignLog case1: "You're delaying my project!"
