Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ieeecs-media.computer.org

Post reply on HN
Print view View original

31–40 of 170 posts

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

#31

Post by wakawaka28 »

dustfinger wrote: post #15
TrueDuality wrote: post #11

Earlier quoted context omitted.

That line is referring to shared libraries linked to a dynamic executable. If a shared library isn't installed or available you will receive an error similar to the following: $ ./main ./main: error while loading shared libraries: librandom.so: cannot open shared object file: No such file or directory Which is indeed a runtime error. There is also the common use case of hot-reloading compiled code which dynamically l…

I understand that is what they meant, but it is not what they wrote. They should have qualified the statement as you did, with the conditions that yield a runtime error. Even if they generalized those conditions that would have been fine. for example: or tries to access a library that it is unable to for some reason without handling the resulting error.

Ah, but the existence of a suitable library in the environment is assumed. So not having it is an unexpected condition.

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

#32

Post by q7xvh97o2pDhNrh »

pnathan wrote: post #24
numbsafari wrote: post #18

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…

> 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 of insight:

    Priority = ((Value * (1 - Risk)) / Cost
(2) The next hundreds of pages go through topics in sequence, like "Architecture" and "Design" (who knew they were different?). Naturally, "Security" is slapped on several hundred pages later.

I couldn't make it through the whole PDF, in all honesty. But I'm quite certain the soul of software engineering is nowhere to be found in there; they've eliminated it entirely and replaced it with stamp-collecting and checklists.

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

#33

Post by [deleted] »

BJones12 wrote: post #17
kragen wrote: 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…

> software engineering has accepted as its charter "How to program if you cannot.". Is that supposed to be a negative? Isn't that the point of any profession? Like are any of these analogs negative?: Medicine has accepted as its charter "How to cure disease if you cannot." Accounting has accepted as its charter "How to track money if you cannot." Flight schools has accepted as its charter "How to fly if you cannot."

[deleted]

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

#34

Post by bigiain »

kragen wrote: 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…

On a tangent here, but...

> The ACM canceled its involvement for excellent reasons which are worth reading: https://web.archive.org/web/20000815071233/http://www.acm.or...

This jumped out at me from the first para there:

" ... also stating its opposition to licensing software engineers, on the grounds that licensing is premature ... "

I wonder what ACM's current thinking on licensing software engineers is almost 25 years further on?

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

#35

Post by 0xbadcafebee »

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 processes used to do the work.

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, much less teach them about it on the job. But that's completely normal in software engineering today, because nobody is expected to have already learned a universal body of knowledge.

I get this thing isn't perfect. But not being perfect isn't a rational argument for not having one at all. And we certainly need to hold people accountable to have learned it before we give them a job. We need a body of knowledge, it needs to be up to date and relevant, and we need to prove people have actually read it and understood it. If this isn't it, fine, but we still need one.

(this is, by the way, kind of the whole fucking point of a trade school and professional licensing... why the fuck we don't have one for software engineers/IT, boggles my fucking mind, if this is supposed to be the future of work)

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

#37

Post by epolanski »

After seeing so much negativity and controversy around this book in the comments, I'm quite convinced to giving it a read.

I've seen so little "engineering" in software world, regardless of the company and how many ivy league devs it hires to be fully convinced that a work of encoding software engineering knowledge is worth the effort, and even attempts like this are valuable reads in such a gigantic vacuum, even just to start a discussion and to be able to disagree on definitions and practices.

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

#38

Post by epolanski »

lifeisstillgood wrote: post #9
michaelsbradley wrote: post #5

Earlier quoted context omitted.

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

The thing here is, this reads like a prissy textbook that no-one can really disagree with but is still not gripping the reality. More HR handbook than blood-red manual. For example, project management. The book covers this but does the usual wrong headed way of imagining there are executives with clear eyed Vision and lay down directives. This is of course not how most projects in most companies are started. It’s a m…

You know that you could be speaking about mining operations or building highways in your post rather than software and everything would apply the same?

I really don't see the argument against the book here in your comment.

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

#40

Post by fragmede »

lifeisstillgood wrote: post #9
michaelsbradley wrote: post #5

Earlier quoted context omitted.

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

The thing here is, this reads like a prissy textbook that no-one can really disagree with but is still not gripping the reality. More HR handbook than blood-red manual. For example, project management. The book covers this but does the usual wrong headed way of imagining there are executives with clear eyed Vision and lay down directives. This is of course not how most projects in most companies are started. It’s a m…

You seem to have quite a bit of lived experience with that particular version of project management. Why not write it yourself?
Post reply on HN