From Softjourn's CEO

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:

1. It is guaranteed to put everyone to sleep, or at the very least having them sending SMS messages or looking at their blackberry.
2. 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.

IP issue #1 – Some of your original code is lost or you do not receive all of the code/solution from your outsourcing provider.

Solution: 
Step a. Keep the code under your control – The source code library can be under your control, on your server or on the server of your provider. If a developer working for your outsourcing provider needs to check out a module, they do so via your source code library and pull it down to their internal network and workstation. When they are done working with that module, they check it back in to your source code library.  In theory this works well, but what if the process of working on the code takes a couple of weeks, what if in the mean time that person quits or is fired from the outsourcing firm, how do you get the latest code that that person was working on. It is, after all, your property.  This solution works well, it works even better with the next step.

Step b.  Work out with your outsourcing provider, a procedure to check that code back in to the source code library at a minimum once a week, even if the developer is still working with it.  In this way you will always have very close to the most recent code in your possession even if something happens to that developer or to your outsourcing provider. In order to assure this is being done, you need to have a process on your side that assures that code is being checked back in once a week or more often depending on what is being delivered.

Concerns about Intellectual Property is often brought up when talked about Outsourcing offshore. There exists many types of concerns some more serious or likely to occur than others. As has been talked about by many experts the best way to prevent these issues from occuring is a combination of having the right processes in place, following through with them and protecting yourself, to the extent possible, legally.

In the following days I will go through 9 common IP concerns and what you can do about them.