Does anybody have a code review checklist for annual reviews?

Question

I have a software engineer that I supervise and management needs a "code review" as part of his annual review. I'm thinking that there might be something out there that could help with this. Something along the lines of a list of categories and maybe a rating (1-5?) in each category with a space for comments. Categories that I'm thinking of:

• Documents code properly
• Clearly organizes source files (?!?)
• Adheres to coding standards
• etc.

I haven't been asked to review any of the usual employee attributes like "ability to work well with others", etc. That will be handled by his non-engineer supervisor. I just need to review his abilities as a developer.

Any ideas on this?

Edit: Norman Ramsey asked "why" management needs this. The answer is that I'm an outside consultant and do not directly supervise this developer. There's nobody else technical in the company. They are doing his annual review and want feedback on the product of his work for the last year. I know that they are frustrated with the fact that their (artifical) deadlines have been missed. But I think they guy does good work. So I want to present this information to management in a formalized way that they can understand.

Answer 1

Well, the things you've listed are a good start. Give him some really useful feedback about his development, though. Is he consistently doing something in a really silly manner? Are his solution soften excessively verbose for something simple (or the opposite, exceedingly complex?)

Make his code review helpful for you, by identifying and aiming to solve productivity hindrances like lacking documentation, etc., and make it useful for him by looking at things he could improve on in terms of his actual code.

Answer 2

A couple of links:

http://www.liberty.edu/media/1414/%5B6401%5Dcode_review_checklist.pdf

I recommend:

http://weblogs.asp.net/tgraham/archive/2003/12/19/44763.aspx

Answer 3

Perhaps an overall "maintainability" score on the code he produces would be useful. Taking into account things such as documentation, use of standards and a section about the types of solutions created, similar to what Anthony described.

I find it useful to have a slightly larger areas to apply scores to. That way you can explain the score by explaining the good aspects and criticize the bad without saying "You suck at this".

Answer 4

I've actually never seen anything quite like that in an annual review in my 20 year career.

Sure, quality of your work is always a consideration. I've just never seen anyone drill down that deep into it.

Completing tasks on schedule always seems to be the big management bugaboo. A developer who takes a bit longer to do a slightly better job tends to be at a disadvantage.

Answer 5

If by 'code review' your management means what everybody else means, your engineer should present some of his code to an audience of his peers, who will criticize and offer suggestions for improvement. It doesn't matter who picks the code, but your engineer should agree that it is ready for peer review and should have time to prepare a presentation.

After the presentation you can evaluate (a) how good is the code relative to the expectations of the peers, and (b) how well does your engineer perform in the review situation? By (b) I mean things like can he distinguish constructive criticism from nitpicking, act favorably on constructive criticism, and quietly deflect nitpicking.

Your idea of a checklist is OK, but being able to convince peers that the code works as advertised is worth ten checklists.

---

Edit: Thanks for revising your question. In this situation it seems more a question of what will convince management. If they are not well informed than they will probably not find peer review very convincing. You might have better luck establishing SEI best practices and so on (not that I know any working engineers who believe in that sort of thing).

Answer 6

I would measure the defect rate of code he has touched. If his code crashes in production frequently or has lots of security issues then...

Focusing on aesthetics such as commenting is less important than other aspects of system qualities.

Answer 7

What categories woukld you use to rate your own code? Use those.

And see also my answer to this question: http://stackoverflow.com/questions/720652/is-it-necesary-to-document-your-code-reviews/720687#720687