When Corporate Lawyers Attack
 If you’re like most programmers, you’ve probably had little, if any, interaction with your company’s legal department. But thanks to the compliance craze, programmers say, software development projects are coming under increasing scrutiny from corporate compliance officers and attorneys.
John Ferrell, a programmer-cum-attorney and intellectual property specialist with Silicon Valley law firm Carr & Ferrell LLP, says companies that wish to mitigate their potential exposure—for intellectual property infringement, regulatory compliance shortcomings, or legal imbroglios of any other kind—would do well to take a page out of Uncle Sam’s playbook.
“I used to work for a company managing software development for the military,” Ferrell says. “It was really hard 20 years ago to get developers to write for the government because it was a really arduous task because of all of the documentation required. Whenever they develop software, they take a very methodical approach. It was a tremendously disciplined process, but that’s the kind of process that you really need if you want to be problem-free.” |
Many organizations already do this. The waterfall method is nothing if not highly structured, process-centric and documentation-intensive. And in Ferrell’s account, it is one approach organizations can use to minimize their risk.
Averse to agile
If he’s right, this presents a problem for agile proponents, who eschew traditional waterfall’s emphasis on documentation and process rigor. This is not to say agile is without rigor. In fact, its adherents argue, agile methods are highly disciplined—they simply give coding, as well as interaction with customers (line-of-business representatives), priority over documentation and adherence to process. It seems like a perfectly reasonable argument. But is it one to which highly risk-averse companies will cotton?
Consider the case of one contributor to Yahoo!’s eXtremeProgramming discussion list. As a result of his company’s Sarbox compliance efforts, this programmer says, coders were given a directive from a C-level executive that all testing was henceforth to be done by the company’s QA department.
Frequent testing, of course, is an integral part of almost all agile programming methods—and yet a C-level executive with little grasp of software development decided (for unfathomable reasons) it wasn’t worth the risk. To add insult to injury, Sarbox is so devoid of technology prescriptions that the C-level executive’s directive was probably superfluous.
eXtreme Programming luminary Ron Jeffries, whose day job is with
software development consultancy Object Mentor, concedes that in today’s fraught legal climate, someone, somewhere, will probably have a problem with agile methods.
“I suppose that some companies, somewhere, will [reject this],” he says. “[But] wise companies never let themselves be run by lawyer-thinking lawyers, in my opinion. Risk aversion is not a business growth strategy.”
More to the point, agile proponents say, extremely risk-averse companies probably aren’t doing agile in the first place, if only because a control culture orientation tends to dominate in such environments.
Crazed by compliance
But in today’s compliance-crazed atmosphere, everyone can go a little batty. With this in mind, companies shouldn’t make the mistake of emphasizing risk mitigation at the expense of their business core competencies, say Jeffries and other agile adherents. “Businesses are in their respective businesses, not in the business of playing legal [cover your posterior],” says agile programming enthusiast Larry Brunelle. “It seems to me that a firm that tries to do right and do it diligently will have a lower risk profile than a firm that does business so as always to have to mitigate legal risk.”
Besides, some agile proponents argue, if you think having enough documentation is going to protect your posterior, you’re sorely mistaken. As The SCO Group demonstrated, an abundance of documentation can prove to be an irresistible target for an aggrieved plaintiff on a fishing expedition.
“A few years ago, Anheuser-Busch established a very strong corporate-wide policy that records must not be kept beyond the legally required times,” argues Jeff Grigg, an independent programming consultant and agile enthusiast. “[Anheuser-Busch] put in place aggressive automated procedures to purge old e-mails, including searching drives for offline copies and killing those too. It seems lawyers are very good at searching through megabytes of data to find informal communications, critical of company policies.”
As Grigg points out, all it takes is one flippant remark—even a comment buried in a Library of Babel’s worth of code. “[This] can be used, out of context, in court cases. Doesn’t matter that a low- level flunky said something cynical, in jest, to another coworker. If the prosecution can prove that problems were known, somewhere in the company, the top-level execs can be held responsible—even more so with SOX.”
Doc-lite Risks
What if a corporate attorney or compliance officer decides agile’s documentation-lite brainstorming sessions and frequent code builds increase the risk of IP litigation—say, copyright infringement charges as a result of inadvertent code-copying?
Hogwash, say coding vets, who point out, “XP teams are highly productive and will typically rewrite rather than accept someone else’s untested code,” argues Grigg. “There are stories of an XP team bringing in a consultant to write some particularly difficult library. Then the XP team discards the consultant’s work and rewrites it from scratch, using the knowledge they gained from the consultant.”
ILLUSTRATION BY SCOTT POLLACK