Definition: A booby trap can cause different results, for example: strip off confidential information sending it to different locations for use by un-trusted persons, cause the shut-down of an application, etc.
Solution: There have probably been more occurrences of booby traps being put in code by in-house staff than by staff at the outsourcing firms, so in either case you need to protect yourself and your code.
Peer or code reviews: A good way to protect you also doubles as a way to assure that the developers are on the right path during the coding phase. Peer reviews are a required Key process area of CMM level 3, Malcolm Baldrige section 5.1 on Design and the Introduction of Products and Services also correlates to SEI (Software Engineering Institute) CMM level 3 peer reviews. In general it is a good practice for any software development lifecycle used.
Peer reviews can take several different forms. One methodology suggests that you do what are called walkthroughs which involves having the developer walk a group of reviewers through his/her code. I would advise against this methodology for two reasons:
- It is guaranteed to put everyone to sleep, or at the very least having them sending SMS messages or looking at their blackberry.
- It is too easy for the developer to skirt around problem areas within his/her code and due to the inattentiveness of everyone else, for potential problem areas to be missed.
A good way to do it would be the following:
Let’s say your development group at the outsourcing firm consists of 5 developers, one as a lead. Create a peer review group consisting of an internal QA person (at a minimum one person from QA, can be more persons) capable of reading and understanding code, the project lead, one person from the client side and the rest of the developers. During each review session a minimum of five persons will be involved: QA person, project lead, client side representative, developer whose code is being reviewed and one additional developer (not every developer needs to review the code of every other person on the team; it is not a wise use of time).
Ahead of the review sessions, send each review team member copies of the code to be reviewed (for the developers send them the code that they are assigned to review, i.e. the code of the team member that they are assigned to review), send copies of coding standards, design specifications for reminder, and an outline of the design session process, i.e. how the code reviews are to be conducted. Each review team member should look through the code on their own before the formal review session and note any questions that they have, any irregularities that they have noticed.
During the peer review session, the QA person (or one of the QA persons) is a good choice to moderate the review session. Each review team member should be given the opportunity to ask the developer questions about why they coded their modules in a particular manner, why they wrote this or that routine, etc.
Peer reviews help to eliminate booby traps firstly by the mere fact of having them. If a developer knows that on a regular basis his/her code is going to be reviewed, they are less likely to put something in to the code in the first place if that was their intent. Secondly it offers the opportunity for a number of people to become familiar with the code making it easier to spot any irregularities that may be put in later on.