Live data from Hacker News

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

ieeecs-media.computer.org

71–80 of 170 posts

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

#71
post #55

Earlier quoted context omitted.

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.

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.

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

#72

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…

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.

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

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

#73

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…

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.

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

#74
post #6

Runtime errors surface when a program runs into an unexpected condition or situation such as dividing by zero, memory overflow, or addressing a wrong or unauthorized memory location or device, or when a program tries to perform an illegitimate or unauthorized operation or tries to access a library, for example. The programs must be thoroughly tested for various types of inputs (valid data sets, invalid data sets and…

Reads like chatgpt, or those insufferable linkedin autogenerated ai questions:

"How would you secure a system?"

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

#75

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?

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

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

#77

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…

> 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

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

#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. It confuses SWE with PM, badly. And it has done so, historically. To the point of wide condemnation.

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

#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 projects with extensive documentation and formalized planning often failed. Today, we have quicker releases, faster feedback, and more direct user communication (what we now call extreme programming or agile). However, this has also led to too much cowboy programming. So it’s important to maintain some level of standards. Might be worth revisiting?

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

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

[deleted]
Post reply on HN