Another approach to desk checking is code reviews and design reviews. Both these practices are a great help to the project when they are done with a spirit of ego-less inquiry. I believe we would save a tremendous amount of time in rework and bugs if we did more design reviews and code reviews.
My thinking is the idea would be to develop it as standard practice so the question is always when. not if. the review would be done. Leadership in this area can be really helpful. I think a great deal of the benefit of the review is the designer or programmer explaining his approach. The process of explaining leads to psycho-clarity. When the programmer puts his ideas in to spoken words, they become clearer to the person.
Giving and receiving feedback during these reviews is important and will be the subject of a future post.
There is no question that making time for reviews like this is essential and almost always falls by the wayside when deadlines loom and corners are cut to meet a deadline.
Peer review is a cornerstone of the scientific method, it ensures the one persons ideas stand up to the scrutiny of the discipline. I’m all for it.
And I wish I had done more of it on the project I am currently finishing. If I had, I would be doing less re-work and bug fixing now.
A parallel process to desk checking is rigourous iterative testing that also exposes flaws in the developers thinking. It applies the cold hard reality of the machine’s logic on the developer. Something that even the most anal-retentive desk checker could miss.
The desk check should occur after the unit and integration testing but before regression, performance, user acceptance and production testing. It would also make sense to walk the full system one more time prior to “going live” in production.