Live data from Hacker News

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

ieeecs-media.computer.org

101–110 of 170 posts

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

#101

This book actually makes some sense to me as a software engineer. We’ve all learned this at school, but they were just scattered pieces of knowledge. This book actually offers a way of systematic organization of useful knowledge in production. Content is actually not for learning, but for quick check and review. The organization might not be perfect, but really is a way of reflecting on our understanding in this fiel…

Did we all? I haven't done a lot of this during my master's and neither did any of my friends (that's across multiple countries/unis).

But yeah, it's a really interesting way to organise the knowledge.

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

#102
post #78

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…

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…

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

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

#103

Earlier quoted context omitted.

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.

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

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

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

#104
post #23

SWEBOK 4 adds a dedicated section for security, but it's painfully 2012 (testing, for instance, centers on the old industry-driven "SAST" vs. "DAST" distinction). It also promotes stuff like Common Criteria and CVSS. The "domain-specific" security section could have been pulled out of the OWASP wiki from 2012 as well: "cloud", "IOT", "machine learning".

Believe it is supposed to be slow-moving, keeping to settled matters. Have those fallen out of favor, or shown to be wrong already?

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

#105

Earlier quoted context omitted.

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…

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

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.

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

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

>What is going on at IEEE?

The IEEE has been a worn-out, irrelevant relic of the past for at least 2 decades now.

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

#107

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…

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.

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

#108

This book actually makes some sense to me as a software engineer. We’ve all learned this at school, but they were just scattered pieces of knowledge. This book actually offers a way of systematic organization of useful knowledge in production. Content is actually not for learning, but for quick check and review. The organization might not be perfect, but really is a way of reflecting on our understanding in this fiel…

Did we all? I haven't done a lot of this during my master's and neither did any of my friends (that's across multiple countries/unis). But yeah, it's a really interesting way to organise the knowledge.

What did you do?

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

#109

So at the start of each chapter, the book has a table of abbreviations and their definitions, called 'Acronyms'. To whoever wrote or edited the book: please lookup the definition of the word 'acronym': "an abbreviation formed from the initial letters of other words and pronounced as a word (e.g. NASA)." Not all of the abbreviations listed are acronyms! Most are just plain old initialisms. Since when has anyone ever t…

From Merriam Webster: a word (such as NATO, radar, or laser) formed from the initial letter or letters of each of the successive parts or major parts of a compound term also : an abbreviation (such as FBI) formed from initial letters : initialism It appears the meaning of the word has changed over time.

There's literally an acronym for that type of acronym that itself is not an acronym: TLA. Three-letter acronym. I get the GP's frustration. When a word that you know the definition of is lost it feels bad.

The hardest for me to accept is the loss of alternate. It now means the same thing as alternative, but it used to refer to switching between possible states, usually in an oscillating manner. Nowadays I alternate between caring and not caring.

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

#110

Earlier quoted context omitted.

Did we all? I haven't done a lot of this during my master's and neither did any of my friends (that's across multiple countries/unis). But yeah, it's a really interesting way to organise the knowledge.

What did you do?

Everything apart from design or software architecture as such. (Unless you include that one weird class on UML and Sybase) Math, electronics, algorithms, encryption, physics, legal side of things like gdpr, networking, compilers, UX, embedded systems, chip design, different CPU architectures, reading research papers, databases (about acid, not specific implementations), ...

But the part of "how to manage the process of creating this" and related ideas you were basically supposed to figure out on your own. Or actively ask the teachers. It feels very sink-or-swim now in retrospect. I've never been explicitly taught about testing for example, but if you didn't write them for your projects, I don't think you'd complete them.

Post reply on HN