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

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.

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.

I agree with your second sentence, but your first sentence is pretty profoundly incorrect. Each of its 413 pages is divided into two columns. I generated a random sample of 10 page numbers associated with column numbers as follows:

    >>> import random
    >>> r = random.SystemRandom()
    >>> [(r.randrange(1, 414), r.randrange(1, 3)) for i in range(10)]
    [(299, 1), (164, 2), (292, 1), (246, 2), (205, 2), (113, 1), (167, 2), (393, 2), (16, 1), (129, 2)]

Page 299/413 column 1 contains: part of a confused description of mathematical optimization in the sense of finding infima, incorrectly conflating it with space-time tradeoffs in software, which is at least a software engineering topic; and the beginning of a section about "multiple-attribute decision making", which is almost entirely about the kinds of decision-making done by corporate management. Though software design is given lip service, if you dig into the two particular "design" approaches they mention, they turn out to be about corporate management again, with concerns such as brainstorming sessions, identifying business cost drivers, staff headcount, presenting ideas to committees, etc. Conclusion: project management, not software engineering.

Page 164/413 (6-12) column 2 is about corporate operations (for which telemetry can be used), corporate operational risk management, and automating operational tasks to improve corporate efficiency. Conclusion: project management, not software engineering.

Page 292/413 (15-3) column 1 is about software engineering economics, specifically proposals and cash flow. Project management, not software engineering.

Page 246/413 (11-12) is a table summarizing chapter 11, which contains both project management and software engineering elements. I'm going to eliminate this point from the sample as being too much work to summarize fully and too hard to avoid interpretation bias.

Page 205/413 (9-13) column 2 is about software engineering management issues such as the difficulty of estimation, the project risks posed by the rate of change of the underlying technology, metrics for managing software, and what software organizational engineering managers should know. Project management, not software engineering.

Page 113/413 (4-14) column 1 is about what a platform standard is, TDD, and DevOps. Mostly software engineering, not project management.

Page 113/413 (6-15) is another summary table page similar to page 246, so I'm eliminating it too.

Page 393/413 (A-5) column 2 is about the SWEBOK itself and the documents it draws from and contains no information about either project management or software engineering.

Page 16/413 (xv) is part of the table of contents, so I'm eliminating it as well.

Page 129/413 (5-12) column 2 is about random testing (software engineering), "evidence-based software engineering" (an utterly vapid section which contains no information about software engineering, project management, or anything else, as far as I can tell), and test cases that force exceptions to happen (software engineering). Conclusion: software engineering, not project management.

So of the seven non-eliminated randomly sampled half-pages in the document, four are about project management, two are about software engineering, and the seventh is just about the SWEBOK. I guess my declaration that it's just a set of management practices was incorrect. It's only mostly a set of management practices. It's not at all only a small fraction.

Your analysis doesn't support your claim. Just to point out one basic flaw, real engineering always has to account for financial realities including cash flow as a constraint or optimization parameter.

I don't think you even understand what software engineering is. If we want to limit the discussion to just software development as a craft and take out the engineering aspects then you might have a point, but that's not what the SWEBOK is about.

And in fairness, most real world software projects can produce good enough results without applying real engineering practices. If you're just building yet another CRUD web app then rigorous engineering is hardly required or even economically justified.

While I agree that "real engineering always has to account for financial realities including cash flow as a constraint or optimization parameter" and that, as I said, "Competent engineers (...) have to understand at least the basics of the management context in which they operate," that's no substitute for attempting to replace real engineering with project management in the curriculum, which is what the SWEBOK is attempting to do—as my analysis conclusively shows!

Contrast, for example, MIT's required courses for a degree in mechanical engineering (https://catalog.mit.edu/degree-charts/mechanical-engineering...): 13 required core subjects of which zero are project-management stuff; one course chosen from a menu of four of which one is "The Product Engineering Process" and another "Engineering Systems Design"; and two electives chosen from a menu of 22, of which three are project-management stuff. The core subjects are Mechanics and Materials (I and II), Dynamics and Control (I and II), Thermal-Fluids Engineering (I and II), Design and Manufacturing (I and II), Numerical Computation for Mechanical Engineers, Mechanical Engineering Tools, Measurement and Instrumentation, Differential Equations, and your undergraduate thesis.

Berkeley's equivalent is https://me.berkeley.edu/wp-content/uploads/2022/03/ME-Flowch..., with math courses, chemistry courses, physics courses, and engineering courses such as ENGIN 7 (Introduction to Computer Programming for Scientists and Engineers), ENGIN 26 (Three-Dimensional Modeling for Design), ENGIN 29 (Manufacturing and Design Communication, which might sound like a project management course but is actually about things like manufacturing process tolerances and dimensioning), MEC ENG 40 (Thermodynamics), and MEC ENG 132 (Dynamic Systems and Feedback). Again, as far as I can tell, there's virtually no project-management material in here. Project management stuff doesn't constitute one tenth of the curriculum, much less two thirds of it.

The software equivalent of Thermal-Fluids Engineering II, Differential Equations, or Thermodynamics is not, I'm sorry, proposals and cash flow, nor is it multiple-attribute decision making, nor is it corporate operational risk management.

The same holds true of chemical engineering (https://catalog.mit.edu/degree-charts/chemical-engineering-c...) or electrical engineering (https://catalog.mit.edu/degree-charts/electrical-engineering...) or basically any other engineering field except "systems engineering". In all of these courses you spend basically all of your time studying the thing your engineering is nominally focused on and the science you use, such as chemical reactions, thermodynamics, fluid mechanics, separation processes, algorithms, electric circuits, and the theory of dynamical systems, and very little time on HR, accounting, and project management.

That's because HR, accounting, and project management aren't real engineering, much as the SWEBOK tries to pretend they are.

Real engineering is a craft based on science, navigating tradeoffs to solve problems despite great intellectual difficulty, and that's just as true of software—even yet another CRUD web app—as of gears, hydraulic cylinders, electric circuits, or chemical plants.

See https://news.ycombinator.com/item?id=41918787 for my thoughts on what a real-engineering curriculum about software would include.