Software Engineering Body of Knowledge (SWEBOK) v4.0 is out [pdf]

There appears to be a lot of hate towards this in the comments (because it's not perfect?), but I feel strongly that we need explicit bodies of knowledge, along with certifications for having been trained on it.

Every company I go to, the base of knowledge of all the engineers is a complete crapshoot. Most of them lack fundamental knowledge about software engineering. And they all lack fundamental knowledge about the processes used to do the work.

That's not how engineering should work. If I hire an architect, I shouldn't have to quiz them to find out if they understand Young's Modulus, much less teach them about it on the job. But that's completely normal in software engineering today, because nobody is expected to have already learned a universal body of knowledge.

I get this thing isn't perfect. But not being perfect isn't a rational argument for not having one at all. And we certainly need to hold people accountable to have learned it before we give them a job. We need a body of knowledge, it needs to be up to date and relevant, and we need to prove people have actually read it and understood it. If this isn't it, fine, but we still need one.

(this is, by the way, kind of the whole fucking point of a trade school and professional licensing... why the fuck we don't have one for software engineers/IT, boggles my fucking mind, if this is supposed to be the future of work)

> if this is supposed to be the future of work

The day computing becomes subject to professional licensure is the day the field of computing will fall into hopeless stagnation, just like every other such field.

Maybe that’s not a bad thing…

Let me hear your pro-stagnation argument

Every time I see someone post this line of reasoning they talk like this, as if other engineering disciplines all have some cert that is the god-tier cert.

While this is true for some engineering fields it's mostly not true and I think that's a good thing because credentialism is bad actually.

Also, architects are not even engineers.

Credentialism is good. It provides both a trustworthy reference point and a method for punishment.

If I want someone to do work, I want them to be licensed/certified. If they are flagrantly unsafe, I want a licensing board or similar to be able to strip that person of their ability to practice that profession. This raises public perception of the profession as a while, avoids a market for lemons, and gives some baseline.

There are too many decisions in life to be able to spend an hour (or more) researching every option. Credentials allow a framework of trust - I don't have to decide if I trust every single engineer; if they have passed their PE exam and not had their certification taken away that is a starting point.

Here's my "pro-stagnation" argument: stagnation and stability are pretty much the same thing. There's a lot of infrastructure that we take for granted because it always works (water purification and distribution, bridges and roads, electrical generation and transmission, automobile engines, the quality of gasoline, the safety of food, etc). You trust that these things will work the way you expect, because they don't change very quickly. Is that stagnation or stability?

Let's start by fixing the language. It's not stagnation, it's predictability.

Civil and mechanical engineering are not static fields. They come up with new materials, new methods, new ideas. They have tooling to understand the impact of a proposed change and standard ways to test and validate things. It is much easier to predict how long it will take to both design and build things. These are all good things.

We would all benefit from fewer cryptoAI startups and frameworks of the week and more robust toolchains tested and evolved over decades.

Credentialism creates a false basis of trust and an arbitrary reference point.

You're just arguing that you want to outsource your own decision making. You actually should interview your candidates before hiring them, whatever credential they have, because it actually is your job to ensure you work with high quality individuals.

Credentialism basically allows the sort of low effort that you're describing and causes many places to rely solely on the credentials, which are obviously never sufficient to find high quality individuals.

What are the jobs you're day dreaming about that require PE exams? I'd bet that requirement is much less common than you think.

So I don't know about you, but I live in America where roads, electrical generation and transmission, water purification, and bridges are all in subpar shape.

That's super broad and I think there are complex reasons why each of these has failed, but it's pretty clear that stagnation hasn't helped and has probably actively caused harm by letting incompetence become too common in these areas.

Why do you think such wrong things about civil and mechanical engineering.

Tell me about all the on time and under budget civil/mechanical engineering projects that are happening.

Do you think that just because they have physics to lean on that they can just like press solve and have accurate estimates spit out?

Edit: I totally agree that more long-lived battle tested software toolchains and libraries would be great though

Such delays are overwhelmingly political, not engineering. The local government demanding yet another environmental impact review is not an engineering cost - it is a scope change.

> Every company I go to, the base of knowledge of all the engineers is a complete crapshoot

Sounds like unfortunate companies to go to.

> much less teach them about it on the job

That is literally how and where people learn the job pretty much everywhere.

> it needs to be up to date

Yeah, it will never be.

> we need to prove people have actually read it and understood it

Why/how?

Credentialism is for more than employers. When I need an electrician or other tradesperson to work on my house, credentials are beneficial. When plans are drawn up for a deck or extension to my house, credentials are beneficial when getting an engineering signoff. Knowing that the local medical facilties employ credentialed doctors is great when I need something done. Etc., etc.

Code that changes introduces new bugs, new bugs can be new security issues. A lower velocity would hopefully mean less changes but higher quality, more thoroughly tested changes.

This is just not the case.

The US has lots of infrastructure that needs repair or replacement, but there are very few areas that do not have clean water, or reliable electricity (Sans extreme weather which causes disruptions in every country), and roads and bridges are all safe to drive on (when was the last time you read about a bridge that collapsed from lack of maintenance?)

The US has its issues, but it does actually have a huge amount of superb, world class infrastructure.

Scope change is really not a foreign concept in the field of software engineering, including politically driven

How do you know things wouldn’t be much much worse if there were no standards for being a civil/structural engineer or architect that have been refined over long periods of time? Imagine municipalities taking the lowest bids by far thrown out there by any rando that decided they can make a few bucks by welding together the supports for a bridge or designing a really interesting building that will just cave in on itself a decade hence.

>> it needs to be up to date

> Yeah, it will never be.

And this particular document will never be up to date. SWEBOK gets updated on the order of every 5-10 years, so it's always going to be dated. This is one reason it's a poor document for its purpose. If they want it to be relevant it needs to be continuously developed and updated. Hire active editors for the different "knowledge areas" (consider even losing that notion, it's very CMMI which is not something to aspire to) and solicit contributions from practitioners to continuously add to, remove from, correct, and amend the different sections. Build out the document they actually want instead of wasting 5-10 years publishing an updated, but still out-of-date, document.

> when was the last time you read about a bridge that collapsed from lack of maintenance?

2022.

https://en.wikipedia.org/wiki/Fern_Hollow_Bridge

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.

You are under this illusion about other fields like architects because you don't work there and you can't tell. You don't know how the sausage is made.

Historically I have tended to learn about a new field WAY too much before I tried to hire people in these fields. The truth is, that makes it hard to hire people (but for good reason - depending on your needs, you need to pass on a lot of people). More recently I have tried to pay very close attention to how people do their work (about whose field I am building an interest). The sad reality of the world is that most people and businesses stay in business entirely through dumb luck and because the world is not usually THAT demanding. And if you have a specific requirement, they won't be able to help "out of the box".

You are imagining this competence. It doesn't exist in most people.

And to compound this, to me, the characteristic of an engineer is that they are capable of learning about a specialty discipline. If you hire an engineer and they are incapable of learning something that's needed in your project, THAT is where their problem is (and yours for not hiring to that.) Engineering is not a trade. Certifications are usually about selling them or gatekeeping. I wish it were possible to certify "engineering progress mindset" - no, it doesn't have an ISO number.

Isn't the reality of things that credentials are a low bar. Yes, even with the legal bar exam, or the PE engineer, etc? When you are hiring, are you really hiring JUST based on that low bar? No! That wouldn't make sense! For example if you have a specific problem, most of the time you are looking for a lawyer who has already worked for a while in THAT specific field. The bar exame is not enough! I feel that's usually the case. And that makes sense. Why just specify "PE engineer"? When there are lots of them who have at least some specialization in the direction you want?

It would have zero value in every process of vetting someone. People don’t care about years of verification in the form of degrees, who do you think will care about some “license to fucking code” given for reading some garbage pdf

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.

I think you missed the purpose of the SWEBOK. It is intended to cover basic fundamentals which don't change much decade by decade. Not the latest JavaScript framework or whatever. Just about everything in the previous version from 2014 is still relevant today.

That made me curious, is there a changelog somewhere on changes between editions?

https://www.computer.org/education/bodies-of-knowledge/softw... - shows a comparison of the TOCs of version 3 (2014) and version 4 (2024). Dates emphasized for my point, it's a decade apart. In 10 years they added 3 chapters and references to DevOps and Agile.

What are you hoping professional licensing might do for you? I can attest that outside of traditional engineering fields, licensing is completely useless and confers roughly the same level of prestige as a Costco membership. I'll send you my engineering ring in the mail if you like (Canada's cheesy contribution to engineering culture).

I don’t think anyone mentioned JavaScript frameworks. Yes everything is perpetually relevant if it is made generic enough, but it is harder to be actionable and truly useful.

They took 10 years since v3 (over 20 if we count from the start) to include security in their discussions. This is my primary issue with the text: It should be a living document.

Choosing a dead document or "mostly dead" if we're generous (with a new version every decade) for a body of knowledge that is constantly growing and developing makes no sense. If you want to publish it as a PDF that's ok, but it needs continuous updates, not decadal updates.

In 2014 Agile barely got a passing mention in the book, 13 years after the term had come into existence and a decade after it had already made major waves in software engineering (many of the concepts that fell under Agile were also already published in the 1990s or earlier and barely mentioned or not mentioned). OOP gets a more substantive section in the 2024 version than the 2014 version when OOP languages had been out for decades before the 2014 one was published. In their added chapter on security they don't even have references for any of section 6.

All of these are things that can be addressed by making it a living document. Update it more regularly so it's actually relevant instead of catching up on ideas from 2009 in 2024 (DevOps as a term dates at least back that far) or ideas from the 1960s and 1970s (OOP) in 2024.

Practitioners are better off reading Wikipedia than this document. It's more comprehensive, more up to date, and has more references they can use to follow up on topics than this book does.

SE is not CS of course. Very few of us will write compilers, for example.

>reliable electricity (Sans extreme weather which causes disruptions in every country)

Freezing temperatures do not cause widespread outages in properly-run countries.

>roads and bridges are all safe to drive on (when was the last time you read about a bridge that collapsed from lack of maintenance?)

2022, when the President was in town in Pittsburg and the bridge there collapsed.

There are tons of physical engineers working on safety critical hardware that are not required to have some BS piece of paper that says they're safe.

You do not need a credential to work on EV charging infrastructure, rockets, crew capsules to ferry astronauts to the ISS, or many, many other things.

That's how you know, because those fields are not less safe. It's an easy comparison.

I completely agree. The trouble is we're so far away from this that all the people who learnt from a few tutorials and never read any books will try to defeat it at every step. They're here in these very comments.

I get that it's possible to build working software without a certificate, in much the same way as someone can do their own electrics. But is it up to standard and safe for the next guy to work on? This is why we have standards.

I think complexity frameworks (like Cynefin) describes it pretty good. When the complexity is low, there are best practices (use a specific gauge of wires in an electric installation in a house or surgeons cleaning according to a specific process before a surgery) but as the complexity goes up best practices are replaced with different good practices and good practices with the exploration of different ideas. Certificates are very good when there are best practices but the value diminishes as the complexity increases.

So, how complex is software production? I’d say that there are seldom best practises but often good practices (in example DDD, clean code and the testing pyramid) on the technical side. And then a lot of exploration on the business side (iterative development).

So is a certificate of value? Maybe if you do Wordpress templates but not when you push the boundary of LLMs. And there’s a gray zone in between.

Licensure injects politics into the heart of engineering.

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. :)