DesignLog principle

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:
Niels, this is Louise.
Louise, this is Niels, who taught me about DesignLogging. Tell what happened.

Bad cycle

coding, testing, coding, testing

Louise:
We had only 1.5 week 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 know what the implementation you will have to 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 - 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 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!