We review products independently, but we may earn affiliate commissions from buying links on this page. Terms of use. On July 19, 2019, contract programmer David Tinley pleaded guilty to charges that he intentionally damaged computers belonging to Siemens Corporation. According to filings in the case, Tinley planted logic bombs into the code he was developing for Siemens at its Monroeville, Pennsylvania location. Those logic bombs, which were sections of code that were timed to create disruption weeks or months after a project was finished, were intended to ensure that Tinsley had a constant stream of revenue from having to fix the problems that were assumed to be bugs. When he was called in to fix a problem, Tinsley simply changed the date on the logic bomb so that it would go off again later. Eventually, another programmer was called in to fix Tinsley's code while he was on vacation, and it was then that the plot was uncovered. 62-year-old Tinsley had been working for Siemens for about 12 years before he was caught, but during that time, he was never under any suspicion. Sentencing is set for November 8, 2019, and Tinsley could spend up to 10 years in prison and pay fines up to $250,000. Hiring Backup Coders So, why am I telling you all of this? After all, the chances you might hire a programmer who deliberately puts logic bombs into your custom code aren't great. And while those chances aren't zero, there are any number of other things that can go wrong when someone is writing code for your organization. "What happens if that person leaves or drops dead?" asks Jack Gold, Principal Analyst at J. Gold Associates. Gold suggests that when you're hiring someone to do development, you always need a backup. After all, custom code is your code. There's no third party to whom you can turn if something goes wrong, unless you plan for it. He also suggested that there are a few other steps that companies need to do to protect themselves during the development process, chief among them are required code reviews. "A code review is probably a best way to find out what's in your code," said Alan Zeichick, Principal Analyst at Camden Associates, "including things like logic bombs, security vulnerabilities, or stupid errors [such as hard wiring the location of a database]." "There are other reasons to do code reviews," Zeichick added. "It helps your development team get a better understanding of how development works, helps junior programmers get a better understanding. Code reviews are also good for helping the team manager get a handle on the quality of the development team and get an estimate of how long it will take to finish the job. Conducting Code Reviews Zeichick said that there are a couple of ways to conduct code reviews. "You can have a team where there are two people working on it or you can meet in a conference room to review code." Teams in which each member reviews someone else's code are growing in popularity as programmers get harder to find. But in larger organizations, periodic meetings to review code are still useful because then several sets of eyes get to help in the review process. Zeichick said that even the most senior programmers should have their code reviewed. So, why did Siemens allow Tinley to go for all those years without a code review? According to comments by his attorney during the trial, Tinley considered his code to be proprietary and used that as an excuse not to have his code reviewed. Why this was allowed to happen is unclear, but both Zeichick and Gold point out that a requirement for code reviews should be part of any contract between a business and an independent programming outfit. Gold suggests that the contract not only mention code reviews but specify how and when they take place. Zeichick noted that some large development shops may do their own code reviews, which he said makes sense. "The best people to do the code review are the people on the development team," he said. Avoiding Malicious Coders Code reviews have been around nearly forever. 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. While it was tedious, we did frequently find oversights, mistakes, misplaced references, or 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 the fact, a refusal to allow code to be reviewed should be a red flag. If you're paying for the code to be written, then your contract can reasonably include a requirement for reviews. Refusal to do that is cause for dismissal. Unfortunately, finding good programmers is hard these days. The demand is high, and in some cases, contract programmers feel they can specify that they don't have to submit to having their code reviewed, even if their contact says that it will be. The best way to avoid such problems is, first, to ask for and then call references for 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, the risks in the development process can be great. Gold points out that an unethical programmer can insert back doors into your code, find ways to steal your customer data or intellectual property, or pass critical data to another company or foreign power. The way to prevent this is to manage continuously, review the work product of your programming staff, and review code before it gets accepted by your code management system.

weiterlesen: RSS Quelle öffnen