Licensing Software Engineers

The XpMailingList discussed this issue, lead by insider CemKaner:

On Sunday, June 1, 2003, at 09:27 AM, KeithRay wrote:

There are a few things going against adoption of SWEBOK licensing.

Most big companies (Apple, MicroSoft, etc.) don't have that heavyweight a development process and would fight against anything perceived as raising their costs. They'd rather move all development to India than be forced to change their practices. I've worked at Apple, and someone in Microsoft's "process group" said they're recommending XP to other groups internally. Big companies fear increased costs more than they fear paying campaign contributions. Just make sure the higher-ups in your companies know the threat of SWEBOK licensing to their bottom-lines.

It would be very easy for an individual engineer accused of malpractice to take the company he works for down with him.

Laywer: did you draw a design in UML before coding?

Defendant: well, we drew some boxes and lines on a whiteboard...

Lawyer: but you have nothing on paper? Why didn't you use the CASE tool?

Defendant: no one uses the CASE tool. My boss said to stop wasting time.

Witness: yes, we didn't install the CASE tool because it couldn't reverse-engineer and it wasn't compatible with WindowsXP.

I thought your way too, Keith, until I raised the licensing issue with some software publishing lawyers at some of the UCITA meetings. For a long time in that process, I sought common ground even though we very often disagreed. (I even formally co-authored one proposal with the senior attorney from Microsoft.) This was an issue that I thought would be common ground.

Anyway, the result, to my surprise, was that these people would go back to their office, discuss with whoever, and come back to the next meeting and tell me that they didn't perceive this as a threat to their interests. This group specifically includes attorneys who represented large software publishers.

Based on that experience, I changed my thinking.

One factor that is easy to dispose of is that the licensing will not necessarily increase the software publisher's labor cost. In fact, the distinction might help limit costs. The in-house developer need not be licensed. Engineering licensing is different from law and medicine. People do electrical, mechanical, etc. engineering all the time without being licensed as engineers. Relatively few graduates of engineering programs become P.E.'s. Only the independents must be licensed. So the only people at MS (etc) who would have to be licensed would be the independent consultants.

There is, by the way, a benefit of this distinction to the employer. In boom times, when employees might jump ship and go independent, or shift back and forth between independence and "full-time" work as they find convenient, the licensing requirement creates an exit barrier for the non-licensed employee. That employee who wants to go independent would have to plan several months in advance, pay a substantial amount of money for the review course and the license exam, study for the exam, etc., all before she could leave her employer to become a consultant. Thus, the non-licensed software engineer is in a weaker bargaining position (has a less credible fix-this-or-I-leave threat) than the licensed engineer. This might reduce staff turnover in boom times (when the effect of turnover is highest, and the probability of rapid turnover due to poor working conditions is greatest).

Let me come back to the liability issue:

I think that the analysis of the software publisher's lawyer is that the licensing does not put them at risk because a customer of off-the-shelf commercial software will find it almost impossible to sue for professional negligence.

• When you buy a commercial product (rather than a consulting service or other service) and its defectiveness causes you economic harm (lose money rather than life or limb), you can sue for breach of contract but not for negligence. The warranty disclaimers, which every court in the United States appears to be enforcing, make it extremely difficult to bring successful breach of contract suits against makers of mass market products. (Instead, you have to sue for fraud or deceptive trade practices, but that line of law is outside of the scope of this thread.)

• When you buy a commercial service (like custom programming or plumbing repair or accounting), and the bad service causes you economic harm, you MIGHT be able to sue for professional negligence. You have to be able to show that the service provider failed to meet the standard of care of the profession (in our case, that will be established by SWEBOK and the IEEE [sub]standards) and you have to prove that the failure caused the harm. As a buyer of software services, MS might be able to sue its consultants. But unless MS is selling custom programming and custom design services, the customers of MS will not be able to sue MS or its consultants for professional negligence.

• When you buy a product or service and the bad product/service causes injury or death or sudden physical damage to a physical object (to my surprise, courts have excluded loss of data from this--they prefer visibly tangible harm), then you (or your survivor) can sue for the injury, death, or destruction and allege that negligence was the cause of the injury. This is a garden variety negligence suit, not a professional negligence suit. Of course, bad engineering practices will be relevant if the lawsuit alleges that the product's design was the cause of the harm (most litigated defects involve manufacturing problems that affect individual instances of the product rather than design problems common to all instances of the product) or that negligent service was the cause of the harm. For example, in the case of Johnson v. General Motors, Johnson sued GM over the death of his grandchild in an accident and GM lost big time (about $8 million) because the defect in the fuel injector software that caused the accident had been known to GM, GM had fixed the bug and had new fuel injector chips, but had chosen not to recall the light trucks that had the bad software (which the courts estimated would have cost GM $48 million) but instead to swap out the chip only for customers who complained of sudden stalling. In this case, GM's failure analysis and fault repair processes were relevant in the lawsuit. Failure to follow accepted engineering practices would be tendered as proof of negligence in such suits, and SWEBOK would be tendered as evidence of accepted practices.

By the way, if you are a third party consultant in a case like GM's, the manufacturer would sue you in an attempt to collect as much of what it pays the customer as it can from your insurance policy. Your insurer would also supply a lawyer (or a legal team) to help the manufacturer defend itself in the lawsuit, to help minimize or eliminate the damages the insurer would eventually have to pay the manufacturer / injured customer. This legal help is itself an expensive boon to the company. If the company has enough consultants on the hook, it might be able to transfer almost all of its litigation costs and losses to the consultants' insurers--This is a genuine strategy, not a hypothetical. I saw legal teams work through it and change their contracting-with-consultants practices during three years of advance planning for potential Y2K litigation.

CemKaner, Professor, Department of Computer Sciences, FloridaInstituteOfTechnology

LessonsLearnedInSoftwareTesting TestingComputerSoftware? BadSoftwareWhatToDoWhenSoftwareFails?.