Early in my career I worked on real time systems and many batch processes. One of the things that myself and others preached was the value of desk checking your program after it was compiled before you ran the program to see if it worked. I ran into huge resistance from most people. The temptation to try it and see if it worked was very compelling. I expect it is similar to the difficulty people have in editing and proofreading material they have written.
I have not written programs for a long time and I was wondering how practices have changed. I am checking with some of my friends, who are still doing development and who agreed with the importance of desk checking, to find out what is the current practices. Our experience at the time was a little time desk checking a program save hours and hours of testing.
I expect the resistance to desk checking is even more extreme now with the on-line aspect of development and the ability to run the program right after you have written it or even while you are writing it. I expect as a result bugs get buried in programs that only reveal themselves in obscure ways and then disappear. I remember way back in the dark ages of assembly language programming I had a program that would stop working for periods of time and then correct itself and carry on. I was perplexed for a long time. I discovered by accident the problem. I occasionally was overwriting a counter and instead of counting down from ten the counter was set at 64K. So the program would have to cycle thru 64K times before it reset the counter properly and start working again. I think with more careful desk checking I would have found that error. I wonder how many more things are lurking in programs.
Maybe having somebody else look at you program before you run it would help. Fresh eyes are always helpful. Trouble is you have to take you ego out of the mix.
I remember Fred Longstaff telling me many years ago that you can tell when a programmer is self-actualized by his comment when the program does not work. He says "What did I do now?", instead of "it worked before and I did not change a thing. It must be a bug in the ………." Everything will be blamed except the author. Sometimes the problem is with a support program but do not become defensive. Check your work first.
Anybody remember about "egoless programming?"
Any comments about desk checking?
We have been leveraging a mix of Agile and Rapid Results mentality to some real breakthroughs in speed and productivity.
The challenge I have seen on keeping everyone (team, client, business and others) in alignment as there is a lot of faith and teamwork needed.
The world of heros quickly diminishes and we have seen teams of 2-4 be able to do things that a team of 6 heros were not able to do.
I guess that is why the Leafs will never win the Stanley Cup.
I remember at Gellman Hayward how difficult it was to teach new people about getting written material edited and proof read. I remember myself finding the comments difficult until I separated myself and my ego from the written material. I expect those issues are still as much an issue today.
I was also thinking how valuable it is to be able to read a program and have it make sense. I now recall all the work we did to improve commenting on programs to make them self documenting.
Love to hear other peoples techniques.
Desk checking as we used to preach it is still useful, but, as you
observed, the world has changed. The cost in elapsed time for the cycle
of edit, recompile, and test used to be measured in hours or days; now
it is measured in seconds or minutes. Of course this can be a mixed
blessing, tempting some developers to test rather than check and think.
Instead of relying on ad hoc desk checking, we have fairly recently
adopted a more formal approach.
We perform peer code reviews for anything developed by someone
relatively junior, and for anything that is large or deemed to be risky.
On the master control automation project, for instance, there is a team
of over a dozen developers working on a suite of applications totaling
over 1.5 million lines of source code, mostly C++. The files reside in a
source code control archive, enabling any previous version of any file
to be extracted. Any particular change requires that the developer (or
group of developers) “check out” the files required before working on
them, so that if others are working on some of the same files there is a
mechanism for merging together each set of changes as part of the “check
in” process. Our code review mechanism is integrated with this process.
A set of changes flagged for review is checked into a side branch of the
main development tree until it has been reviewed. We have a review
checklist to guide the reviewer.
Some of the benefits of the code review process that we see include:
* Knowing that one’s code is going to be reviewed may cause one to
take more care-pride of workmanship, if you like
* The reviewer may turn up design problems
* The reviewer may discover coding errors
* The reviewer will learn about the implementation, providing a
backup resource to the original developer
Obviously all of this costs in the short term, but should pay off in the
long term as better delivered code with fewer design and coding errors.
Hope this helps.
Desk checking made a lot of sense when the feedback loop between writing a
program and running it had a lot of delay (tens of minutes versus seconds).
I’ve been researching the Agile approach that advocates tighter feedback loops.
One practice used in Extreme Programming is to keep the feedback tight by
having a complete build of the program take less than 10 minutes.
Some of the other benefits of desk checking like catching syntax errors or logic
errors is also accomplished by the Extreme Programming practice of paired
programming: one person, with the keyboard is the driver, the other is the
navigator.