Live data from Hacker News

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

ieeecs-media.computer.org

91–100 of 170 posts

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

#91
post #79

Yes, there’s been a lot of negativity toward earlier versions of this document. It’s been around for a while and represents a formal, structured, and rigid approach to software development. Historically, it reflects the 1990s era, when waterfall was the preferred method, and there was a push to make software engineering a licensed profession. At the time, we were also in a “software crisis” where large, expensive pro…

There was literally nothing in the SWEBOK which dictated a particular approach to software development, formal or otherwise. It has always been just a high-level list of knowledge areas and common definitions.

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

#92
post #24

Earlier quoted context omitted.

Even he admits, he had to start somewhere.

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 enterp…

> If I were to write a swe body of knowledge, it would be in koan form, more than likely.

http://www.thecodelesscode.com/contents

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

#93
post #3

It's so unfortunate that this effort is still alive. The ACM canceled its involvement for excellent reasons which are worth reading: https://web.archive.org/web/20000815071233/http://www.acm.or... It's probably also worth reading Dijkstra's assessment of the "software engineering" field (roughly coextensive with what the SWEBOK attempts to cover) from EWD1036, 36 years ago. > Software engineering, of course, presents…

Wanted to call out the specific requirements for what the ACM wanted out of their participation in creating a core body of knowledge (from the linked reasoning): * It must reflect actual achievable good practice that ensures quality consistent with the stated interest; it is not that following such practices are guaranteed to produce perfect software systems, but rather that doing so can provide reasonably intuitive…

The ACM's insistence on clearly delineated roles and specialties seems so bizarre and misguided. Having defined roles necessarily implies some rigidity in allowed process and organizational structure, which seems out of scope for an engineering body of knowledge.

If you insist on defined roles then you end up with something like Scaled Agile Framework (SAFe) or Large Scale Scrum (LeSS). Which aren't necessarily bad methodologies if you're running a huge enterprise with a complex product portfolio and need to get productive work out of mediocre resources. But not good approaches for other types of organizations. The SWEBOK, for better or worse, largely steers clear of those issues.

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

#94
post #3

It's so unfortunate that this effort is still alive. The ACM canceled its involvement for excellent reasons which are worth reading: https://web.archive.org/web/20000815071233/http://www.acm.or... It's probably also worth reading Dijkstra's assessment of the "software engineering" field (roughly coextensive with what the SWEBOK attempts to cover) from EWD1036, 36 years ago. > Software engineering, of course, presents…

As much as I like Dijkstra and this particular article of his (it is an assigned reading in my "Software Engineering" class), developing any large scale software that we have today starting from formal methods is just a fantasy. I understand the importance of learning formal methods (discrete math, logic, algorithms, etc.), but they are not nearly enough to help someone get started with a software project and succeed…

Formal methods have advanced enough now that any competent software engineer should know that it is at least an option. It's obviously not practical or necessary to apply everywhere but in any sufficiently large piece of software there are likely a few modules where applying formal methods would allow for faster, higher quality delivery at lower cost. Making those trade-offs and selecting appropriate approaches is the fundamental essence of engineering as a profession.

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

#95
post #89

Earlier quoted context omitted.

>> 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…

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?

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

#97
post #89

Earlier quoted context omitted.

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.

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

#98

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…

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

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

#99
post #89

Earlier quoted context omitted.

>> 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…

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.

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.

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

#100
post #89

Earlier quoted context omitted.

>> 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…

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.

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.

Post reply on HN