Software Engineering Body of Knowledge (SWEBOK) v4.0 is out [pdf]
IEEE’s new version of the Software Engineering Body of Knowledge (SWEBOK) aims to codify “generally accepted” practices and support certification and curricula, but many engineers criticize it as outdated, error‑prone, and overly focused on management rather than the technical craft of building software. Commenters contrast SWEBOK’s approach with how other engineering disciplines are taught, question whether formal bodies of knowledge and licensing would improve software quality, and highlight the risk of giving false assurances of competence. A smaller group argues that, despite its flaws, some standardized, shared foundation is necessary in a field where baseline knowledge and process vary wildly between organizations.
Purpose and Positioning of SWEBOK v4.0
- Guide to “generally accepted” software engineering knowledge, aiming to support curricula, certification, and role definition.
- Intends to be slow‑moving and focus on fundamentals rather than fast‑changing tech.
Strong Critiques of the Project
- Long‑standing criticism that SWEBOK is ill‑conceived; ACM exited the effort years ago, arguing it can’t meet reasonable requirements for a software engineering body of knowledge.
- Some see it as a political/credentialing project more than a genuine engineering reference.
- Dijkstra’s old critique of “software engineering” as “how to program if you cannot” is cited as resonant with SWEBOK’s flavor.
Management vs. Technical Focus
- Multiple commenters argue the book over‑emphasizes project management, economics, and process at the expense of actual software techniques (debugging, design, algorithms, etc.).
- A random sampling of pages is presented to claim most content is management‑oriented.
- Others counter that real engineering must account for cost, risk, and organizational context.
Quality and Accuracy Concerns
- Specific passages (e.g., on runtime errors) are dissected and called technically confused, oversimplified, and sometimes just wrong.
- Editing issues (misused terms like “acronym”, odd examples like “accessing a library” as an error) contribute to a perception of sloppiness.
- Critics say debugging, a central engineering activity, is treated superficially.
Licensing, Certification, and Credentialism
- One camp wants a standard body of knowledge plus certifications, akin to PEs in other fields, to reduce variability in engineer competence and improve public safety.
- Another camp warns licensing would cause stagnation and false assurance; cites poor outcomes in heavily credentialed government/defense software.
- Debate over whether credentialism actually correlates with quality, or just encourages box‑ticking.
Comparisons to Other Engineering Disciplines
- Some argue other engineering degrees are dominated by domain science (mechanics, thermodynamics, circuits), with relatively little management; SWEBOK inverts this.
- Others respond that software’s breadth and volatility make a general, domain‑agnostic body of knowledge inherently problematic.
Security and Timeliness
- New security chapter is seen as dated (SAST/DAST framing, older standards like Common Criteria) and missing modern perspectives.
- Critics say a decadal PDF cannot keep pace; call for a continuously updated, “living” reference instead.
Perceived Value and Alternatives
- A minority finds SWEBOK useful as an organized checklist or overview of topics they already “half‑know”.
- Several suggest that curated books, practical handbooks, and even informal resources (e.g., essays, koan‑style wisdom, open‑source architecture write‑ups) are more valuable in practice.
- Despite harsh criticism, some readers are motivated to read it precisely because it is controversial.