A certain Korean corporation is known to be very agile. They use the best tools to make the best software: Word for code review; a bug tracker with more ticket states than there are projects; an automatic test suite which require people to eyeball each test result, compare it to reference, and choose "pass" or "fail"; a specially crafted developer version of an OS, with explicitly disabled debugger. They use the best process to ensure each project is a guaranteed success (not any process - The Process).
Part of The Process is a periodic verification of code reviews done in Word. Let me tell you the story of
(no, don't ask me why there's a "checklist" in the name)
The Formal Code Review, being formal and all, cannot be done in some simple tool like Word. Naturally, it must be done in Excel. Let's go through it. First, you need to prepare yourself:
The Preparation consists of listing all bugs found in a file. Note: a file; guess what happens when you have multiple files to review.
You put in standard info, like department, name, review time, date, file, and then the defect list. For each defect line, you enter a description with some cryptic categorization. ST CL 3-1? We'll get to that later. Of course you also need to specify why the author introduced given defect. If you're not a mind reader, there's a standardized answer - "Wrong". Deal with it.
When you feel prepared enough, you advance to the actual code review Result:
Here you have a round number, like in a boxing match, recorder (the person filling it up), file (again), version (always 1.0a; always), line count because that's the most important information in any review, and some type (nobody knows what that is). Then the fun starts: attendance. You see, The Process dictates that each member of the team makes their own code review Excel files, and we then sit in a conference room and discuss what we've found. Doing it with some online tool is not formal enough, apparently. Besides the name, department and the title of each attendee, you need to specify if he attended or not. Because attendees are known not to attend is some alternate reality. And we have a mystical column named Agreement, which needs to have an O inside. A keg of beer to anyone who knows what that means.
Going further, besides some useless statistics which must be filled (with date - again), you need to copy paste the defect list form the Preparation. Why? Maybe you have not prepared enough and some defects get lost between sheets? Note that each defect must have a date added. Someone really likes dates in The Process.
Now, about those defect categories - you have a nice specification what to put in there:
For each line you have to consult this page, until you memorize it all. But one page is not enough:
You need to assign even another defect category to each line. These ones have comments! In Korean too!
After all of this, you need to fill in an even more formal defect list:
"But all this is in Korean!" - you might say. "Well, fuck you and learn!" - you might hear back.
After the dust clears, everyone can go home happy that another Formal Code Review (Checklist) has been successfully completed, and the software got undoubtedly better. The Process never fails.