Every couple years somebody comes up with the idea, “Hey! let’s
license software engineers!” Committees are formed, standards drawn
up, and papers smoothed out by waiting bureaucrats–and then
everything falls apart and the software profession returns to the
status quo, because everybody realizes the plan just isn’t feasible.
I’ve been following this cycle for years, and even parodied it in the
second chapter
of my story
Code the Obscure.
But the most recent wave of calls for licensing are getting
serious. The drive this time comes from the national security
kick. Computer systems are vulnerable because of bugs, and bugs are
human failings caused by programmers, so–the reasoning is hard to
fight–let’s ensure we have good programmers through licensing.
Licensing for software engineers is no longer an arcane topic to be
considered by the existing and aspiring members of a single field.
Once you license programmers and other computer professionals, you
open the door to making their employers liable for their work.
And the converse is also true: when you demand that government “should
pass a law…Make companies liable for insecurities” as leading
security expert Bruce Schneier does in his most recent
Crypto-Gram Newsletter of October 15,
you inevitably force those companies to set standards for their
employees. And the whole set of questions ties directly into our
national security debate.
No wonder calls for licensing and liability have been
getting louder. The only political arguments that seemed
to be aired against the trend represent the free-market
attitude, “Government shouldn’t get involved in business
matters,” which is no argument at all so far as I’m
concerned.
The unanimity of experts on this topic has made me reluctant to share
my own point of view; I did not even circulate my recent article
The National Strategy to Secure Cyberspace: a Sober Cyberassessment
very widely. But I have felt pushed to speak out since reading the
November 2002 issue of the Communications of the ACM,
published by the
Association for Computing Machinery,
one of the oldest and most important organizations in computing.
This issue of their journal take up the topic of licensing (by no
means for the first time) and offers a number of perspectives. And
once again, the ACM and its guest authors come down overwhelming
against licensing. Only one article, by the renowned David Parnas,
offered firm support. The other points of view expressed ranged from a
wavering “Well, they’ve started licensing software engineers in Texas
and it hasn’t hurt anybody yet” to an extreme suggested by the title
“Software engineering considered harmful.” While I think the title of
that article is misleading, the author does essentially convey the
idea that the term “software engineering” is an oxymoron.
(I should point out that licensing is different from
certification. Licensing is backed by government requirements and
forms a legal requirement to practicing one’s profession.
Certification is much less intrusive, being just a statement by some
organization that you have mastered certain material, such as Windows
networking.)
The software profession’s repeated refusals to countenance licensing
are impressive, because pragmatic circumstances pressure the leaders
of every profession toward licensing.
By licensing you reassure your customers of your competence. To take a
more cynical point of view, licensing creates a barrier to entry that
restricts the number of practitioners in a field and consequently
raises the salaries of those who cross the barrier. And one mustn’t
leave out the attractiveness of the mystification factor! (”We can’t
challenge what she tells us; she’s a licensed software engineer.”)
Admittedly, as one article in the ACM journal points out, there are
also disincentives to licensing. Licensing gives customers and others
a hook on which to hang lawsuits and the types of regulation called
for by Schneier and others. But these pressures exist anyway;
licensing could equally function as a way to stave them off.
The continuing evolution of the software field, which makes licensing
untenable, also dooms attempts to make companies liable for software
flaws. The problems faced are stated in my earlier-cited
article:
But unfortunately, the state of the fifty-year-old software field is
nowhere near mature enough that we can justly hold programmers
responsible for bugs. While we have made progress in many areas–for
instance, we have programming languages that rule out the dreaded
buffer overflows responsible for most security flaws–we are always
running behind. This is because new programming techniques keep being
invented (for instance, popular languages like ASP and PHP for
building dynamic Web pages) and we cannot anticipate their security
ramifications.Liability for software bugs would fall particularly hard on
the field of free and open source software, which ironically provides
the most robust and secure products.…
The proposal for certifying security professionals may also be
misguided. Certain basic habits of good security can be delineated,
but I don’t know how well they can be formally taught or tested. The
particular vulnerabilities and attacks change so frequently that no
certification can ensure public preparedness.
My article does not rule out ratings by insurance companies
to enforce best practices, or holding companies liable
for egregious, deliberate negligence.
The particular issue of free software has also come up in
the licensing debate around
UCITA.
I highly respect the people who yearn for liability, but I
challenge them to come up with a concrete proposal for such a law that
would actually work and be fair. All I’ve seen so
far are vague demands and a lot of righteous indignation. I think the
debate should continue, because I’d like to find a solution–we just
have to look realistically at the state of software and think ahead to
the consequences of legal action.
Would licensing or liability be helpful?
No need for laws.
The solution to this problem is really quite simple. Expect better code from your employees, provide them with the tools needed to produce good code, and replace employees who can't (or won't) live up to the standard.
I'm not advocating perfect coding, but it's very clear to me that good coding is well within anyone's reach.
Case in point: NASA. There is a group of programmers in Houston (last i checked) that write the software for the space shuttle. It's as close to perfect code that you can get. For good reason.
Also, i've yet to encounter a bug in the code that runs my car. Anyone here find a bug in their cars? Why? Because there is a degree of accountability that Ford, GM, etc.. must face up to.
Then there's the issue of pride. Why does open source code tend to be better than some closed source code? Why does it get patched so fast when a bug is found? Because some programmer has his or her name plastered on that chunk of code. People don't like to look the idiot.
My point is simply that good code is entirely possible. Running off and whining to your local congressperson to write a law so you don't have to do as much Quality Control (both in code and in people) is irresponsible.
No need for laws.
Anyone here find a bug in their cars?
Car companies find bugs all the time. Hence we have what is known as the "recall".
Don't confuse licensing with liability!
Andy -- While I agree completely that software licensing is a bad idea, I'm troubled by the way your article seems almost to equate licensing with liability. They're two completely separate issues with, I think, only the most tenuous of connections. I think, for example, that certain forms of liability are appropriate for commercial software vendors -- particularly, liability for failure to deliver the advertised/marketed functionality. (If properly written, these would actually *encourage* free software, which would simply be made available rather than marketed with implied promises/warranties.) And there are kinds of voluntary licensing that I would see as too harmless to bother opposing (although you might say that these are really certification, not licensing). -- Nathaniel
It depends on your objective
I don't see that licensing leads to liability for bugs any more than doctors are liable for patients who die of incurable diseases. In any field of endeavor there are recognized limits as to what can be done. Licensing would lead to liability for negligence but that liability possibly already exists.
The advantage of licensing as I see it lies entirely in raising the salaries of developers and in lending weight to their statements. It would prevent the all too common scene in which the PHB says "Do it this way", the programmer says "That's not going to work", and the PHB gets the last word "Do it this way, or else". PHBs do not generally make much progress arguing with the legal staff.
I see very little difference between open source developers and lawyers. In each case the raw material of their work is publically available (source code and written law, respectively) and the value is in the manipulation of that material.
However, lawyers are licensed and it is not easy to get that license. As a result, lawyers are well compensated and their opinions cannot be argued against by a non-lawyer (else you are quickly accused of practicing law without a license).
I see licensing of software engineers as nothing but a good thing. I think current developers often fear it thinking they will not pass "the bar" to become licensed and will lose their jobs. The approach to that problem is to grandfather people in using various criteria which would automatically admit a reasonable and significant subset of those writing code today.
Finally, the proposed profession should be software engineering not computer science. This parallels the licensing of civil engineers but not physicists.