AVOIDING MALICIOUS CODERS
Code reviews have been around for ages. When I was managing a team
of programmers for a large government facility, we’d go over mind-
numbing lines of COBOL every Friday afternoon. It was tedious work,
but we frequently found oversights, mistakes, misplaced references, and
other coding errors. The fact is, we all make mistakes, and a sensible
review makes the code better for everyone.Unfortunately, programmers sometimes resent code reviews, believing
they’re a waste of time. Others say they don’t want people second-
guessing their code. But a refusal to allow code to be reviewed should be
DUHGÀDJ,I\RX¶UHSD\LQJIRUWKHFRGHWREHZULWWHQWKHQ\RXUFRQWUDFW
can reasonably include a requirement for reviews. Refusal to do so is
cause for dismissal.8QIRUWXQDWHO\¿QGLQJJRRGSURJUDPPHUVLVGL̇FXOWWKHVHGD\V7KH
demand is high, and in some cases, contract programmers feel they
don’t have to submit their code for review, even when their contract
says otherwise.7KHEHVWZD\WRDYRLGVXFKSUREOHPVLV¿UVWWRDVNIRUDQGWKHQFDOO
references from previous work. Second, enforce code reviews from day
one. That way, they become a habit, and programmers refusing to have
reviews can be dismissed immediately—before they become critical to
the development process.Unfortunately, risks in the development process can be great. Gold
points out that an unethical programmer can insert back doors into your
FRGH¿QGZD\VWRVWHDO\RXUFXVWRPHUGDWDRULQWHOOHFWXDOSURSHUW\DQG
pass critical data to another company or foreign power.The way to prevent this is to manage continuously, review the work
SURGXFWRI\RXUSURJUDPPLQJVWD̆DQGUHYLHZFRGHEHIRUHLWJHWV
accepted by your code management system.Wayne Rash
PC MAGAZINE DIGITAL EDITION I SUBSCRIBE (^) I SEPTEMBER 2019