←back to thread

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

(ieeecs-media.computer.org)
180 points beryilma | 6 comments | 21 Oct 24 19:16 UTC | HN request time: 1.258s | source | bottom
Show context
0xbadcafebee ◴[21 Oct 24 23:47 UTC] No.41909738[source]▶
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)

replies(7): >>41909853 #>>41910131 #>>41910397 #>>41910615 #>>41910691 #>>41910982 #>>41911740 #
eacapeisfutuile ◴[22 Oct 24 01:51 UTC] No.41910397[source]▶
> 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?

replies(1): >>41910560 #
1. Jtsummers ◴[22 Oct 24 02:19 UTC] No.41910560[source]▶
>> 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.

replies(1): >>41910852 #
2. nradov ◴[22 Oct 24 03:11 UTC] No.41910852[source]▶
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.
replies(3): >>41910935 #>>41911128 #>>41911171 #
3. eacapeisfutuile ◴[22 Oct 24 03:28 UTC] No.41910935[source]▶
That made me curious, is there a changelog somewhere on changes between editions?
replies(1): >>41910951 #
4. Jtsummers ◴[22 Oct 24 03:32 UTC] No.41910951{3}[source]▶
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.
5. eacapeisfutuile ◴[22 Oct 24 04:15 UTC] No.41911128[source]▶
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.
6. Jtsummers ◴[22 Oct 24 04:22 UTC] No.41911171[source]▶
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.