Swebok

This is the month for review of the IEEE's Software Engineering Book of Knowledge. This is an attempt to define the body of knowledge of our profession, in a way that can lay the groundwork for a licensed profession.

Usually I'd ignore something like this. There are hoards of IEEE standards out there that are routinely ignored by anyone doing commercial software development. Mostly they were written by academics and those engaged in large government projects. Business people don't consider government as a synonym for efficiency.

But Cem Kaner, whose judgment I've learned to respect, does take it seriously. In his blog he says “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.”

So how flawed is the Swebok? This is a busy month for me, so I haven't had time to dig into it in any detail. Just reading a few sections is enough to raise a few red flags, and certainly to confirm the view that Swebok puts undue emphasis on plan-driven development, to a degree that rules out agile approaches.

The first section I looked at was the one on design. Clearly Swebok sees design as a separate activity from programming - a view that's contrary to most of us in the agile movement. It hints at a very detailed level of design being required as an input to coding and testing - although it's impossible to say how detailed it actually thinks it should be.

The choice of books it came up with wasn't awful - although I was alarmed that GangOfFour didn't make it to the recommended list.(It's in the secondary 'further readings' but not in the primary 'Recommended References' section.)

The process section relied heavily on the notions of measurement based control, which is seriously flawed since I've observed that you CannotMeasureProductivity. It's clearly strongly based on Scientific Management principles, and as such utterly ignores the role of people and human interaction issues in process. Again since Individuals and Interactions trump Process, this is a huge hole in the body of knowledge.

The requirements section concentrates on producing a comprehensive System Requirements Specification prior to commencing development - again very much waterfall thinking. (Interestingly it shows a spiral model picture - but only for producing the requirements document!) There's no sense of exploring cost trade-offs in requirements - in my view a vital element of any requirements work.

Well that's it for a quick scan. I may look more in the future. But fundamentally I agree with Cem Kaner. Our industry is not sufficiently mature to produce a body of knowledge of this kind yet. We are still learning much about software development, and at the moment there are a number of schools of thought. The software engineering community has its own opinions, which may be appropriate for a portion of software development. But there is no widespread consensus yet.

(For further commentary see Robert Levy.)