←back to thread

180 points beryilma | 4 comments | | HN request time: 0.001s | source
Show context
kragen ◴[] No.41907822[source]
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 itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".

https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF

The ACM's criticisms, however, are much harsher and much more closely focused on the ill-conceived SWEBOK project.

The IEEE's continued involvement calls the IEEE's own credibility and integrity into question—as do its continued opposition to open-access publishing and its recent history of publishing embarrassingly incompetent technical misinformation in IEEE Spectrum (cf., e.g., https://news.ycombinator.com/item?id=41593788, though there are many other examples). What is going on at IEEE?

replies(9): >>41908044 #>>41908088 #>>41908468 #>>41908554 #>>41908654 #>>41908727 #>>41908778 #>>41909589 #>>41911466 #
1. TrueDuality ◴[] No.41908654[source]
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.

replies(1): >>41910917 #
2. nradov ◴[] No.41910917[source]
The ACM's insistence on clearly delineated roles and specialties seems so bizarre and misguided. Having defined roles necessarily implies some rigidity in allowed process and organizational structure, which seems out of scope for an engineering body of knowledge.

If you insist on defined roles then you end up with something like Scaled Agile Framework (SAFe) or Large Scale Scrum (LeSS). Which aren't necessarily bad methodologies if you're running a huge enterprise with a complex product portfolio and need to get productive work out of mediocre resources. But not good approaches for other types of organizations. The SWEBOK, for better or worse, largely steers clear of those issues.

replies(1): >>41914240 #
3. kragen ◴[] No.41914240[source]
This is actually a general problem with the SWEBOK: it isn't an engineering body of knowledge. It's a set of management practices like the ones you describe. It doesn't steer clear of those issues, at all.
replies(1): >>41914626 #
4. nradov ◴[] No.41914626{3}[source]
Only a small fraction of the SWEBOK covers management practices and it doesn't dictate any particular methodology. Competent engineers might not need to do management but they have to understand at least the basics of the management context in which they operate.