Software Engineering, Ethics and the FBI Virtual Case File System

Published on Monday, 29 January 2007

Technologists who spend their time working on line of business projects are typically exposed to subtle and not-so-subtle messages about business ethics. Most recently, the implementation of the Sarbanes-Oxley Act has touched most of our lives in some way, shape, or form. At a bare minimum, it has heightened our awareness of how terribly wrong things can go when the trust afforded certain practices (accounting and reporting, in the case of SOX) proves to be misplaced.

As strong as the reaction to Enron, Tyco, and WorldCom debacles was; it surprises me again and again to see just how willing the corporate community is to shrug off major IT project failures. This is especially true when you compare the strict regulations, codes of conduct, and ethical guidelines in place for the public accounting community and the almost complete lack of anything resembling these structures in the professional software engineering community. Enron and Tyco may be examples of otherwise ample process controls gone awry. In the software engineering community, we don’t even have a process.

Software Engineering, Ethics and the FBI Virtual Case File System

The recent IT conversations Podcast on the utter failure of the project to stand up the FBI Virtual Case File system reinforced this point for me. For those of you who want to get the down and dirty on the FBI Virtual Case File story, the IEEE has a pretty good article containing what appears to be a fairly objective history of the project. “So what does this have to do with ethics?”, you ask.

I think most laypeople, let alone professional software engineers, perceive about halfway through the IEEE article that this project was a train wreck in the making. So why was this not apparent to the 200 plus contractors and countless FBI staff involved in the project? Have we, as a profession, been conditioned into silence or is virtually every software project so fraught with journeys into uncharted waters that we have become ethically ambivalent to the dangers?

The real “story within the story” here is the tale of Matthew Patton, a security contractor who, despondent about lack of management concern, posted his concerns about the project to a Web-based bulletin board. The Web post, which has been archived online, lead to an FBI investigation, denial of his clearance, and a situation in which Mr.Patton had little choice but to resign. Perhaps it’s just me but I find it a bit ironic that Mr.Patton was forced out of the FBI project in the same year that an FBI employee made it onto Time magazine’s “Person of the Year” cover along with whistleblowers from Enron and WorldCom.

There have been movements in our profession (if I can refer to it as such) to institute a code of ethics and similar measures. Both IEEE and the Association of Computing Machinery (ACM) support a unified software engineering code of ethics. With membership in these organizations representing just a fraction of the population engaged in software engineering, this code has nowhere near the professional impact of similar measures released by organizations such as the American Institute of Certified Public Accountants (AICPA). Where does this leave us as software engineers?

  • We need more people like Matthew Patton amongst our ranks because there are certainly more train wrecks like the FBI Virtual Case File system just waiting to happen.

  • We have to start taking software engineering as a profession seriously. The fact that late and over-budget projects have come to represent the norm needs to change.

  • We need to think long and hard about how to police ourselves as a profession. Accounting and auditing tried, failed, and then Congress stepped in and told them how to run the show as part of Sarbanes-Oxley. If we don’t figure out how to do this ourselves, someone will tell us how we have to run our show.

We as software engineers are bound by the same laws that we created. There are no silver bullets for the issue of ethics in software engineering. There is only the fact that a lot of software projects are delivered late, over-budget, or both. It is our ethical obligation to speak up or support those who do speak up and call out the doomed death-march projects before they’ve done too much harm – to us, to our organizations, and to our profession.