Live data from Hacker News

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

ieeecs-media.computer.org

151–160 of 170 posts

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

#151
post #138

Earlier quoted context omitted.

Any suggestion for a handbook or compendium that you consider to be a worthy alternative?

Although any random bathroom-wall graffiti is better than the SWEBOK, I don't know what to recommend that's actually good . Part of the problem is that people still suck at programming. “How to report bugs effectively” https://www.chiark.greenend.org.uk/~sgtatham/bugs.html > is probably the highest-bang-for-buck reading on software engineering. Not having read it, I hear The Pragmatic Programmer is pretty good. Code…

I wrote:

> Code Complete was pretty great at the time.

Unfortunately it seems that Steve McConnell has signed the IEEE's garbage fire of a document. Maybe if you decide to read Code Complete, stick with the first edition.

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

#152

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.

> having a course based on this as a credential.

I'm assuming you mean a single course? If so, this material would not be a standalone course. It would be baked into the entire bachelor's degree program. Some of the topics would maybe be more advanced or something that need to be demonstrated by being an EIT or writing the appropriate exams. For example, chapter 15 on engineering economics is a single class, but chapter 17 on mathematical foundations would cover at least 4 classes (discrete math, differential calculus, integral calculus, probability).

The US of A did have a software engineering principles and practices of engineering (PE) exam, but it's been discontinued, and I haven't managed to find an archived snapshot of the exam spec. I'm not American, but I think there is a common fundamentals of engineering (FE) exam [1] that has to be written to register as an EIT and then the PE [2] has to be written to be licensed and given the PE.

I'm not familiar with which American schools were ABET accredited in software engineering, but in Canada, several schools do have accredited software engineering majors. You can review the curriculum and see a fair amount of alignment to the SWEBOK topics. Again, some of these chapters could be split across multiple courses, but some chapters look more like a couple of weeks in one class.

For comparison, there is a 61 page industrial and systems engineering body of knowledge [3] available from the IISE (Institute of Industrial and Systems Engineers), which is really just a couple short paragraphs on each topic, a list of key areas within each, and a list of reference books. At a quick glance, all of the areas correspond to sections in the industrial FE [4] and the industrial PE [5].

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

I'm not an engineer. I did an associates in engineering technology in Canada, so I'm a "pretengineer" at best. As far as I know, engineers in Canada have a discipline and then areas of practice. For industrial, there are 9 different areas of practice, but people are generally licensed to practice in 1 to 3.

In my region, software is not even broken out into its own areas of practice. Software is an area within computer engineering. I think software is way too vast right now and the expectations are much too big. So, the traditional engineers have much more limited scope problems. But I could be limited by my perspective and lack of license.

[1] https://ncees.org/exams/fe-exam/

[2] https://ncees.org/exams/pe-exam/

[3] https://www.iise.org/Details.aspx?id=43631

Links to PDFs

[4] https://ncees.org/wp-content/uploads/2022/09/FE-Industrial-a...

[5] https://ncees.org/wp-content/uploads/2024/10/PE-Ind-Oct-2020...

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

#154

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.

> having a course based on this as a credential. I'm assuming you mean a single course? If so, this material would not be a standalone course. It would be baked into the entire bachelor's degree program. Some of the topics would maybe be more advanced or something that need to be demonstrated by being an EIT or writing the appropriate exams. For example, chapter 15 on engineering economics is a single class, but chap…

In the US most engineers do not have the PE and many (might be most, but I couldn't find the numbers) do not take the FE exam.

In the States most people working on software have computer science degrees, not software engineering degrees.

In general there is not a huge amount of certification overhead for engineers in the US, despite what some people seem to think, and I'm quite happy that's the way it is.

I was mostly looking for perspectives on how requiring credentials like these impacted actual work and workplaces.

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

#155

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 feel strongly that we need explicit bodies of knowledge, along with certifications for having been trained on it.

...

> 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

Why do you feel strongly about it? Why isn't that how software engineering should work?

While I don't disagree with your belief that improved software engineering skill foundations would be better for the industry as a whole, I find your conclusion unpersuasive because it seems to imply that "something is better than nothing." But as this sibling comments alludes to (an ACM rebuttal to SWEBOK):

https://news.ycombinator.com/item?id=41907822

https://web.archive.org/web/20000815071233/http://www.acm.or...

I find the ACM's argument more persuasive:

```

The SWEBOK effort uses the notion of “generally accepted knowledge” as a cornerstone, specifically excluding “practices used only for specific types of software.” We believe very strongly that, for software, this is approach is highly likely to fail and that the opposite approach — primarily focusing on specific domains — is far more likely to succeed. The central reason is that software engineering addresses a much broader scope than traditional engineering disciplines. ...

```

And I tend to agree with their conclusion:

```

Overall, our assessment has led us to the conclusion that the SWEBOK effort is geared aggressively towards trying to define an overall level of professional practice for all of software engineering that would implicitly provide assurances to the public. Furthermore, we believe strongly that it will fail to lead to an achievable level of professional practice in a reasonable time and that, in failing, it may lead to a situation in which the public is provided with false assurances of the quality of software systems ...

```

To conclude, I'll address a point you raised which I have a hunch could be the root premise of your argument:

> Every company I go to, the base of knowledge of all the engineers is a complete crapshoot. Most of them lack fundamental knowledge...

If this is what you've seen at every company you go to, it could be that the common thread is you. I've worked at a variety of companies over my career, and quite a few suffered from the issue you mention. But on the whole, at least half of them (and by proxy, the engineers and engineering orgs I've worked in) have been the exact opposite. The technical bar is very high, the body of knowledge is established, clearly defined, and rigorously enforced; in doing so, these organizations were able to ship durable, high quality code with high velocity and a low defect rate even as the business expanded dramatically and we experienced setbacks and false starts. While I don't think my experience is universal, I also don't think it's unique either.

My unsolicited advice to you would be to try and find a company that has the technical bar you would like to see and work there for a while. Failure is a much poorer teacher than success. There is certainly room for software engineering to evolve as a practice, but for the aforementioned reasons (articulated by folks in far greater, well thought through detail than I have), I don't believe SWEBOK holds the keys.

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

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

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

> Choosing a dead document or "mostly dead" if we're generous for a body of knowledge that is constantly growing and developing makes no sense.

As the document says, it is _not_ the body of knowledge. It is a guide to the body of knowledge. The body of knowledge exists elsewhere, in the published literature.

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

#157
post #24

Earlier quoted context omitted.

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…

> The IEEE has been riding this horse for a very long time Well, there's your mistake right there. You're supposed to be riding an ox. All this talk of oxen and horses got me curious about the PDF, so I went and took a look. It's really far worse than you've described. I couldn't stomach it for too long, but here's some highlights: (1) The first ~65 pages are about "requirements gathering." Page 60 offers up this gem…

> like "Architecture" and "Design" (who knew they were different?)

O'Reilly, for one. ISBN 9781098134358's blurb says, "You'll learn the distinction between architecture and design..."

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

#158

Earlier quoted context omitted.

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…

At least alternate and alternate have different pronunciations.

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

#159
post #87

Earlier quoted context omitted.

What exactly about the SWEBOK is awful? Could you give us a link to the documentation of reasons? Which sections of the SWEBOK cover topics that professional SWEs don't need to understand, and which major topics are missing? It isn't possible to be a competent engineer, beyond the most junior levels, without having a pretty solid grasp of project management. You might not need to be a good project manager but in orde…

The basic problem is you're wrong and also right: it all depends. That is widely understood as the senior+ swe mantra. The SWEBOK, on the contrary, asserts "it does not depend" and that in a sense is the core problem. For a detailed takedown, the ACM's is the most famous, there are others that v3 sparked. I'm sure v4 is sparking it's own detailed analysis ... I'm bowing out to go do my day job now. :)

I cannot find this "ACM's detailed takedown of the SWEBOK", could you provide a better reference?

edit: found it: https://web.archive.org/web/20000815071233/http://www.acm.or...

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

#160
post #150

Earlier quoted context omitted.

You're reading WAY too much into it. Sometimes things are meant to be simplified, and this is one of those cases. We are essentially talking about a brief description of something in a textbook. >This implicitly asserts that dividing by zero is always unexpected, that all runtime errors are unexpected, and that dividing by zero always causes a runtime error. None of these are true. You are assuming basically all of t…

Well, you asked what was wrong with it, and I answered. If you don't bother to read the answer to the question you asked, that's on you. I do agree that a division-by-zero exception is a good example of a runtime error, and—as I said in the comment you are purportedly responding to!—that the examples are intended to refer to common errors. (However, most of them fail to do so, evidently due to the ignorance of the au…

I didn't miss anything you said. I did read your comments and frankly I don't have the time to address the level of banality therein. My position is that you are erecting and burning an elaborate straw man based on the least reasonable reading of a general statement, and you don't understand who the audience is. If someone has to be told what a runtime error is, that means they don't necessarily know it. That definition is totally adequate for the purpose of conveying the concept.

You accuse me of being personal but your comments are some of the most pompous crap I've read in ages.

>And the document goes on for hundreds of pages at this atrocious quality level.

Oh so you read the whole thing? Lol

Post reply on HN