Live data from Hacker News

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

ieeecs-media.computer.org

61–70 of 170 posts

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

#61

Earlier quoted context omitted.

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

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.

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

#62
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".

Are there any freely available books you would recommend for 2024 security in software engineering?

(Freely available in the same sense that the SWEBOK is I mean; you can read it free of charge without DRM and without having to resort to piracy. Doesn't have to be a fully free book that goes as far as to allow modification and redistribution although that is an extra nice bonus if any of your suggested books are like that.)

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

#63
post #55

Earlier quoted context omitted.

Let me hear your pro-stagnation argument

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…

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.

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

#64

Earlier quoted context omitted.

Let me hear your pro-stagnation argument

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

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

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

#65
I would love to hear someone that actually works in a place that requires credentials like the PE comment on having a course based on this as a credential.

There are way too many software engineers with lofty ideas about how physical engineers can magically know all the answers to all the problems they could ever have.

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

#66

Earlier quoted context omitted.

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

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…

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.

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

#67

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…

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

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

#68

Earlier quoted context omitted.

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

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

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.

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

#69

Earlier quoted context omitted.

Maybe that’s not a bad thing…

Let me hear your pro-stagnation argument

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.

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

#70
Taking a look at the index, a couple of issues which would make it not in my interest:

1- very heavy on process management. Not against studying it, but 70% is a lot. Also it isn't a very objective area of knowledge, there's hundreds of ways to skin the pig, which probably explains why it takes so much space.

2- a whole chapter about architecture, which isn't a very well regarded as an independent branch of computer science/systems engineering knowledge.

3- at last, in the technical section, databases shares a section along with fundamentals like processes and operating systems?

All in all it looks like a dictionary/checkbox built by a comittee rather than a consistent perspective on software.

And as a textbook it's got problems as well as mentioned, it has a doubtful taxonomy and too heavy on process engineering.

Tl;dr: I'm getting Orange Eating 101 vibes https://youtu.be/pR6z-gm5_cY?t=38&si=F7knCRNcFET7nki7

Anyways, my 2 cents, won't be reading it.

Post reply on HN