Live data from Hacker News

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

ieeecs-media.computer.org

11–20 of 170 posts

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

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

> or tries to access a library I had to open the PDF and find this line to confirm. It really says that. It reads as if claiming that any program that accesses a library will then have a runtime error. That is obviously not what they intended, but I have read it over a few times now and cannot see another interpretation.

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 loads and unloads shared libraries without restarting the entire application. It needs to be done carefully but you've likely used an application that does this. Failure to load a library, or loading an incompatible one will also create a runtime error.

Looks like there is a lot of bad generalizations in here, but they are technically correct on this one.

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

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

As much as I like Dijkstra and this particular article of his (it is an assigned reading in my "Software Engineering" class), developing any large scale software that we have today starting from formal methods is just a fantasy.

I understand the importance of learning formal methods (discrete math, logic, algorithms, etc.), but they are not nearly enough to help someone get started with a software project and succeed at it.

So, if not "software engineering", then what should we teach to a student who is going to be thrown into the software world as it exists in its current form?

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

#15

Earlier quoted context omitted.

> or tries to access a library I had to open the PDF and find this line to confirm. It really says that. It reads as if claiming that any program that accesses a library will then have a runtime error. That is obviously not what they intended, but I have read it over a few times now and cannot see another interpretation.

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.

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

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

Wanted to call out the specific requirements for what the ACM wanted out of their participation in creating a core body of knowledge (from the linked reasoning):

    * It must reflect actual achievable good practice that ensures quality consistent with the stated interest; it is not that following such practices are guaranteed to produce perfect software systems, but rather that doing so can provide reasonably intuitive expectations of quality.
    * It must delineate roles among the participants in a software project.
    * It must identify the differential expertise of specialties within software engineering.
    * It must command the respect of the community.
    * It must embrace change in each and every dimension of its definition; that is, it must be associated with a robust process for ensuring that it is continually updated to account for the rapid change both in knowledge in software engineering and also in the underlying technologies.
It then details exactly how SWEBOK fails to meet those (which all still seem to be relevant) and comes to the following scathing conclusion:

    Overall, it is clear that the SWEBOK effort is structurally unable to satisfy any substantial set of
the requirements we identified for bodies of knowledge in software engineering, independent of its specific content.

I haven't read the SWEBOK but some spot checking and a review of the ToC seems to indicate they have not meaningfully taken that criticism into an account.

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

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

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

#18
post #7

Swebok is an attempt to look at the whole ox Cook Ding was cutting up an ox for Lord Wenhui. As every touch of his hand, every heave of his shoulder, every move of his feet, every thrust of his knee — zip! zoop! He slithered the knife along with a zing, and all was in perfect rhythm, as though he were performing the dance of the Mulberry Grove or keeping time to the Jingshou music. “Ah, this is marvelous!” said Lord…

Even he admits, he had to start somewhere.

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

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

> The ACM canceled its involvement for excellent reasons which are worth reading

Interesting, thanks for the hint; the paper is from 2000 though, and as it seems it would need an update; just checked e.g. the "roles" point and it seems there were significant changes. I also think ACM has rather different goals than IEEE.

> It's probably also worth reading Dijkstra's assessment of the "software engineering" field

Well, was there anything or anyone that Dijkstra didn't rant about ;-)

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

#20
post #13

If you really want someone interested in software development to run away, hand them books like this one.

This was my first thought.

If this ever starts to get thought in CS university courses the amount of devs would dramaticaly reduce due to trauma.

Post reply on HN