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

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?

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 mess - reality impinges on the organisation, pain and loss and frustration result in people making fixes and adjustments. Some tactical fixes are put in place, covered by “business as usual”, usually more than one enthusiastic manager thinks their solution will be the best, and a mixture of politics and pragmatism results in a competition to be the one project that will solve the problem and get the blessed budget. By the time there is an official project plan, two implementations exist already, enough lessons learnt that the problem is easily solved, but with sufficient funding all that will be abandoned and have to be rebuilt from scratch - and at a furious pace to meet unrealistic expectations that corners will be cut leading …

That manual needs to be written.

Very interesting. Particularly their notion (paraphrasing) that SWEBOK attempts to record generally recognised knowledge in software engineering while excluding knowledge about more specific subdomains of software.

That over-deference towards general knowledge coupled with some sort of tie to a similar Australian effort probably explains why the software engineering degree I began in Australia felt like a total waste of time. I remember SWEBOK being mentioned frequently. I can't say I've gotten terribly much value out of that learning in my career.

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?

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.

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

> 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 ;-)

Since we’re talking Dijkstra, perhaps “structured programming” is a starting place.

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?

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.

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

I really don't think he means "cannot" in the sense of "presently don't know how," but more categorically--along the lines of chiropractic being the profession for those who cannot cure the way an MD can. I think it's an indictment of hackery.

I am guessing that you didn't get value out of it probably because you didn't work in avionics, medicine, defense, etc? Those industries where a software fault is unacceptable and has to work for decades.

In some industries like avionics and medical instruments, the programmer might be personally held responsible for any loss of life/injury if it could be proven.

Having read Software Engineering and Formal Methods 25 years ago, I could say that IEEE leans heavily towards SE like it is a profession.

It is not going to be appealing to the crowd of Enterprise developers who use Python, Javascript, Web development etc.

> In some industries like avionics and medical instruments, the programmer might be personally held responsible for any loss of life/injury if it could be proven.

If you aren't a PE, it's hard to hold you personally responsible unless they can show something close to willful, deliberate misbehavior in the development or testing of a system even in avionics. Just being a bad programmer won't be enough to hold you responsible.

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.

Formal methods have advanced enough now that any competent software engineer should know that it is at least an option. It's obviously not practical or necessary to apply everywhere but in any sufficiently large piece of software there are likely a few modules where applying formal methods would allow for faster, higher quality delivery at lower cost. Making those trade-offs and selecting appropriate approaches is the fundamental essence of engineering as a profession.

>What is going on at IEEE?

The IEEE has been a worn-out, irrelevant relic of the past for at least 2 decades now.

If your software kills someone (by mistake), personal guilt is a punishment one never completes.

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.

Maybe if developing large-scale software starting with the formal methods we have today is just a fantasy—and that's plausible—we shouldn't be trying to formalize "software engineering". Imagine trying to formalize medicine before Pasteur, motor engineering before Carnot, mechanical engineering before Reuleaux, or structural engineering before Galileo. Today, we do have relevant bodies of formal knowledge that are enough to help someone get started with a project in those areas and succeed at it. As you say, that knowledge doesn't exist yet for software.

So what would you teach an architect in 01530 or a mechanical engineer in 01850? In addition to the relatively sparse formal knowledge that did exist, you'd make them study designs that are known to have worked, you'd apprentice them to currently successful master architects or mechanical engineers, and you'd arrange for their apprenticeship to give them experience doing the things people already do know how to do.

The SWEBOK will not reduce the number or severity of software faults; it probably increases both.

Yes, because those would describe, respectively, faith healing, spending money whenever you happen to have bills in your pocket, and levitation through Transcendental Meditation, rather than what we currently call "medicine", "accounting", and "flight schools".

"Software engineering" as currently practiced, and as promoted by the SWEBOK, is an attempt to use management practices to compensate for lacking the requisite technical knowledge to write working software. Analogs in other fields include the Great Leap Forward in agriculture and steelmaking, the Roman Inquisition in astronomy, dowsing in petroleum exploration, Project Huemul in nuclear energy, and in some cases your example of faith healing in medicine.

There are three absolutely key differences here.

The first is that, if you get a four-year college degree in mining or civil engineering, you will not spend much of those four years studying management practices; you will spend it studying geology, the mechanical properties of rocks and soil, hydrology (how water flows underground), and existing designs that are known to work well. You probably will not build a mine or a highway, but you will design many of them, and your designs will be evaluated by people who have built mines and highways.

The second is related to why you will not build a mine or highway in those four years: those are inherently large projects that require a lot of capital, a lot of people, and at least months and often decades. Mining companies don't have to worry about getting outcompeted by someone digging a mine in their basement; even for-profit toll highway operators similarly don't have to worry about some midnight engineer beating them to market with a hobby highway he built on the weekends. Consequently, it never happens that the company has built two highways already by the time there is an official project plan, and I am reliably informed that it doesn't happen much with mines either.

The third is that the value produced by mining operations and highways are relatively predictable, as measured by revenue, even if profits are not guaranteed to exist at all. I don't want to overstate this; it's common for mineral commodity prices and traffic patterns to vary by factors of three or more by the time you are in production. By contrast, much software is a winner-take-all hits-driven business, like Hollywood movies. There's generally no way that adding an extra offramp to a highway or an extra excavator to a mine will increase revenue by two orders of magnitude, while that kind of thing is commonplace in software. That means that you win at building highways and mining largely by controlling costs, which is a matter of decreasing variance, while you win at software by "hitting the high notes", which is a matter of increasing variance.

So trying to run a software project like a coal mine or a highway construction project is a recipe for failure.

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.