“I can't fix the bug.”
“Why not? Is it too hard to fix?”
“No, it'd take maybe 5 minutes to fix it.”
“So fix it.”
“Ah, but I can't do that until we document it.”
“Okay, document it.”
“Can't do that.”
“Why not?”
“Because then we have to have the document reviewed by the committee.”
“What committee?”
“Exactly. We don't have one.”
“Can we get one?”
“A commitee, sure. A committee that counts, no.”
“Why not?”
“Any committee formed by this company will be invalid because this company's processes are not properly certified.”
“Since when?”
“Since the new law that was passed. If I just go in and fix that bug and deploy the fix to our end-users, we'd be committing malpractice and could be sued.”
“What?!?”
“By the way, have I shown you the quotes for the Software Malpratice Insurance...”
While the above drama was obviously produced by Kraft, it's slightly scary to think this could actually happen. That the second-hand fear I feel when hearing about my doctor's malpractice wranglings could promote itself to first-hand is sobering.
MartinFowler re-blogged Cem Kaner's blogation on SwEBoK and the implications it has on licensing software engineering. Martin gleaned a great quote:
If the SWEBOK is the basis for the licensing exam, the practices in the SWEBOK will be treated as the basis for malpractice lawsuits. People who do what is called good practice in SWEBOK will be able to defend their practices in court if they are ever sued for malpractice. People who adopt what might be much better practices, but practices that conflict with the SWEBOK, will risk harsh criticism in court. As the basis for a licensing exam, SWEBOK becomes as close to an Official Statement of the approved practices of the field as a licensed profession is going to get.
What's wrong with SwEBoK? Both Martin and Cem relate concerns that it is filled with ideas that they believe are not proven, and in some/many cases actually harmful to the process of building software. As I've been on the agile bandwagon for a while, on the surface, I'd have to share their concern.
Cem closes with this, and I thought I could at least re-broadcast to the 2 people who read my blog:
Only 500 people participated in the development of SWEBOK and many of them voiced deep criticisms of it. ...
I don't see a way to vote on the 2003 version of SWEBOK. If I did, I would urge you to vote NO.
But even though you cannot vote to disapprove this document, you can review it, criticize it, and make clear the extent to which it does fails reflect the better practices in your organization.
To the extent that it is clear that there is no consensus around the SWEBOK, engineering societies will be less likely to rely on it in developing licensing exams (and less likely to push ahead with plans to license software engineers), and judges and juries will be less likely to conclude that “It says so in the SWEBOK. That must be what the best minds in the profession have decided is true.”
Please, go to www.swebok.org ASAP.
tags: ComputersAndTechnology
