A core of the matter here is that good software development is heavily involved with _wisdom_, and in some sense, wisdom can not be stated badly, but must be oblique.
I'm more than happy to sign onto a reasonable certification. Many good reasons for it. I am, personally, fond of the idea that an ABET certified BSCS should be ground floor level. Other ideas have been floated...
But this particular work is really, really, really awful. For reasons that are well documented.
In the most fundamental sense, the IEEE doesn't understand what professional SWEs need, in appropriate portions. It confuses SWE with PM, badly. And it has done so, historically. To the point of wide condemnation.
What exactly about the SWEBOK is awful? Could you give us a link to the documentation of reasons? Which sections of the SWEBOK cover topics that professional SWEs don't need to understand, and which major topics are missing?
It isn't possible to be a competent engineer, beyond the most junior levels, without having a pretty solid grasp of project management. You might not need to be a good project manager but in order to make competent engineering decisions you have to understand how your tasks fit into the whole.
The basic problem is you're wrong and also right: it all depends.
That is widely understood as the senior+ swe mantra.
The SWEBOK, on the contrary, asserts "it does not depend" and that in a sense is the core problem.
For a detailed takedown, the ACM's is the most famous, there are others that v3 sparked. I'm sure v4 is sparking it's own detailed analysis ... I'm bowing out to go do my day job now. :)
A comprehensive list of the SWEBOK's problems would run to tens of thousands of pages, so it will surely never be written. But here's a summary of my own comments in this thread on the topic. I think they cover most of the important aspects.
As its Introduction clearly explains, the SWEBOK is primarily a work of political advocacy. One of its political goals is a particular division of labor in software that has been tried, has failed, and has largely been abandoned, as I explained in https://news.ycombinator.com/item?id=41918800. It also advocates basing that division of labor on a form of credentialism which has also been tried in software and continues to fail, as I explained in https://news.ycombinator.com/item?id=41931336.
As explained in https://news.ycombinator.com/item?id=41907822, the ACM canceled their involvement in the SWEBOK effort in part because they are opposed to this political program, leaving it entirely in the hands of the IEEE. Unfortunately, today's IEEE seemingly lacks the technical competence at an organizational level to avoid publishing utter nonsense through many channels. (Many IEEE members are of course highly knowledgeable, but evidently they aren't the ones in charge.)
As a result, the substantive content of the SWEBOK is also riddled with astoundingly incompetent errors; I dissected a representative paragraph in https://news.ycombinator.com/item?id=41915939, finding 12 serious factual errors in 86 words. As is commonly the case with text written with no concern for veracity, it takes roughly 20 times as much text to correct the errors as it did to make them.
The content of the SWEBOK that actually concerns the engineering of software is not just as error-riddled as the rest of it, but also very limited†, displaced by project-management information, as I showed with a random sampling in https://news.ycombinator.com/item?id=41916612. This focus would represent a major departure from accredited curricula in real engineering‡ fields such as mechanical engineering, chemical engineering, and electrical engineering, as I showed by surveying top university curricula in those fields in https://news.ycombinator.com/item?id=41918011. The SWEBOK represents an attempt to substitute management process for technical knowledge, an approach which is well known not to work. This is what Dijkstra was criticizing about the so-called "software engineering" field 35 years ago in EWD1036, which I linked from the third comment of mine linked above.
(Unlike Dijkstra, I do not think that it is futile to apply an engineering approach to software, but that is not what studying project management is.)
Even within the scope of project management knowledge, the SWEBOK primarily advocates the kinds of management approaches that work well in industries such as mining and civil engineering. However, as I explained in https://news.ycombinator.com/item?id=41914610, fundamental differences between those fields and the engineering of software make those management approaches a recipe for failure in software, even with ample engineering competence.
Engineering is a craft based on science, using formalized theory to navigate tradeoffs to solve problems despite great intellectual difficulty. But, as I explained in https://news.ycombinator.com/item?id=41914332, our current formal theory of software is not strong enough to provide much help with that task. That does not mean that teaching people how to engineer software is hopeless; in that comment I outlined a general approach, and in https://news.ycombinator.com/item?id=41918787 I give more details about the specific things people engineering software need to know, which has relatively little overlap with the SWEBOK. This current state of theoretical knowledge means that you cannot meaningfully assess software engineers' competence by testing their mastery of formal theory, because the formal theory we have is only somewhat relevant to actually engineering software. Instead, you must observe them attempting to engineer some software. That is why credentialism is so especially counterproductive in this field. That would still be a fatal flaw in the SWEBOK even if its content were primarily focused on the actual engineering of software rather than project management.
As I said in https://news.ycombinator.com/item?id=41914444, the health-care equivalent of the approach advocated by the SWEBOK is faith healing; the agricultural equivalent of the approach advocated by the SWEBOK was the Great Leap Forward; and the petroleum-exploration equivalent of the approach advocated by the SWEBOK is dowsing.
______
† "The food here is terrible! And such small portions!"
‡ The engineering of software is real engineering, as Hillel Wayne convincingly demonstrated in https://www.hillelwayne.com/talks/crossover-project/, but this is still a controversial point. So I picked three fields which I hope everyone can agree are real engineering. The "software engineering" that the SWEBOK is about, and that Dijkstra was criticizing, is not the engineering of software and is not in fact engineering at all.
Cook Ding was cutting up an ox for Lord Wenhui. As every touch of his hand, every heave of his shoulder, every move of his feet, every thrust of his knee — zip! zoop! He slithered the knife along with a zing, and all was in perfect rhythm, as though he were performing the dance of the Mulberry Grove or keeping time to the Jingshou music.
“Ah, this is marvelous!” said Lord Wenhui. “Imagine skill reaching such heights!”
Cook Ding laid down his knife and replied, “What I care about is the Way, which goes beyond skill. When I first began cutting up oxen, all I could see was the ox itself. After three years I no longer saw the whole ox. And now — now I go at it by spirit and don’t look with my eyes. Perception and understanding have come to a stop and spirit moves where it wants. I go along with the natural makeup, strike in the big hollows, guide the knife through the big openings, and following things as they are. So I never touch the smallest ligament or tendon, much less a main joint.
“A good cook changes his knife once a year — because he cuts. A mediocre cook changes his knife once a month — because he hacks. I’ve had this knife of mine for nineteen years and I’ve cut up thousands of oxen with it, and yet the blade is as good as though it had just come from the grindstone. There are spaces between the joints, and the blade of the knife has really no thickness. If you insert what has no thickness into such spaces, then there’s plenty of room — more than enough for the blade to play about it. That’s why after nineteen years the blade of my knife is still as good as when it first came from the grindstone.
“However, whenever I come to a complicated place, I size up the difficulties, tell myself to watch out and be careful, keep my eyes on what I’m doing, work very slowly, and move the knife with the greatest subtlety, until — flop! the whole thing comes apart like a clod of earth crumbling to the ground. I stand there holding the knife and look all around me, completely satisfied and reluctant to move on, and then I wipe off the knife and put it away.”
“Excellent!” said Lord Wenhui. “I have heard the words of Cook Ding and learned how to care for life!”
I'm convinced slowing feeding students, and having them produce good low-level codebase(s) (e.g. OSs, compilers) is a great Way to "holistically" teach them CS, much better than what's happening usually. "C is a razor-sharp tool"!
The Master might say something like this, if translated crudely -
Software engineering is programming professionally, with a dialogue on quality. Everything else is details.
The IEEE has been riding this horse for a very long time, in the face of very serious criticism (see the ACMs comments from a quarter century ago).
The presentation of it is _not even wrong_. It reads like a mid level manager at a very old enterprise firm wrote out what important at their firm, and took no material care for other ways. The SWEBOK has been that way for as long as I can remember ( an aside: my experience of Software Engineering academia has been so deeply negative to the point I wrote the field off in 2013. Decoupled from reality, PM oriented, toy studies- irrelevant. The SWEBOK is an artifact of that world. I should dip back in... Maybe Google & MS Research have done the real work here...)
There's a body of _practice_ that is mildly incidental. Most acronyms are fads. Lots of ephemeral technologies that only exist as painful grimaces. IE- CORBA- SOAP, etc...
Project management and quality management are also essentially contingent. One company does this. One that. Waterfall here. Agile there. Whirlpool the other.
What you're left with as non contingent and timeless is in the area of compilers, algorithms, etc. Which is not SWE at all.
If I were to write a swe body of knowledge, it would be in koan form, more than likely.
> The IEEE has been riding this horse for a very long time
Well, there's your mistake right there. You're supposed to be riding an ox.
All this talk of oxen and horses got me curious about the PDF, so I went and took a look. It's really far worse than you've described.
I couldn't stomach it for too long, but here's some highlights:
(1) The first ~65 pages are about "requirements gathering." Page 60 offers up this gem of insight:
Priority = ((Value * (1 - Risk)) / Cost
(2) The next hundreds of pages go through topics in sequence, like "Architecture" and "Design" (who knew they were different?). Naturally, "Security" is slapped on several hundred pages later.
I couldn't make it through the whole PDF, in all honesty. But I'm quite certain the soul of software engineering is nowhere to be found in there; they've eliminated it entirely and replaced it with stamp-collecting and checklists.
Being a music teacher is a well-established play that winds up being a reasonable money maker. It's not super lucrative but it is understood and legible.
I've done that; I set it up so that the table was the record stream, then a materialized view with the current state would be refreshed asynchronously when an insert happened. Fast as lightning. Wouldn't do it by default for everything tho.
reply