Live data from Hacker News

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

ieeecs-media.computer.org

111–120 of 170 posts

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

#111

After seeing so much negativity and controversy around this book in the comments, I'm quite convinced to giving it a read. I've seen so little "engineering" in software world, regardless of the company and how many ivy league devs it hires to be fully convinced that a work of encoding software engineering knowledge is worth the effort, and even attempts like this are valuable reads in such a gigantic vacuum, even jus…

I love the notion of having standard definitions and practices that are specifically not agreed on and will be argued about every time they come up.

To move forward you need a starting place.

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

#112

Earlier quoted context omitted.

Credentialism creates a false basis of trust and an arbitrary reference point. You're just arguing that you want to outsource your own decision making. You actually should interview your candidates before hiring them, whatever credential they have, because it actually is your job to ensure you work with high quality individuals. Credentialism basically allows the sort of low effort that you're describing and causes m…

Credentialism is for more than employers. When I need an electrician or other tradesperson to work on my house, credentials are beneficial. When plans are drawn up for a deck or extension to my house, credentials are beneficial when getting an engineering signoff. Knowing that the local medical facilties employ credentialed doctors is great when I need something done. Etc., etc.

I think complexity frameworks (like Cynefin) describes it pretty good. When the complexity is low, there are best practices (use a specific gauge of wires in an electric installation in a house or surgeons cleaning according to a specific process before a surgery) but as the complexity goes up best practices are replaced with different good practices and good practices with the exploration of different ideas. Certificates are very good when there are best practices but the value diminishes as the complexity increases.

So, how complex is software production? I’d say that there are seldom best practises but often good practices (in example DDD, clean code and the testing pyramid) on the technical side. And then a lot of exploration on the business side (iterative development).

So is a certificate of value? Maybe if you do Wordpress templates but not when you push the boundary of LLMs. And there’s a gray zone in between.

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

#113

Earlier quoted context omitted.

Why do you think such wrong things about civil and mechanical engineering. Tell me about all the on time and under budget civil/mechanical engineering projects that are happening. Do you think that just because they have physics to lean on that they can just like press solve and have accurate estimates spit out? Edit: I totally agree that more long-lived battle tested software toolchains and libraries would be great…

Such delays are overwhelmingly political, not engineering. The local government demanding yet another environmental impact review is not an engineering cost - it is a scope change.

Licensure injects politics into the heart of engineering.

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

#114

Earlier quoted context omitted.

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…

> 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 resp…

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

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

#115
post #87
post #78

Earlier quoted context omitted.

I'm more than happy to sign onto a reasonable certification. Many good reasons for it. I am, personally, fond of the idea that an ABET certified BSCS should be ground floor level. Other ideas have been floated... But this particular work is really, really, really awful. For reasons that are well documented. In the most fundamental sense, the IEEE doesn't understand what professional SWEs need, in appropriate portions…

What exactly about the SWEBOK is awful? Could you give us a link to the documentation of reasons? Which sections of the SWEBOK cover topics that professional SWEs don't need to understand, and which major topics are missing? It isn't possible to be a competent engineer, beyond the most junior levels, without having a pretty solid grasp of project management. You might not need to be a good project manager but in orde…

The basic problem is you're wrong and also right: it all depends.

That is widely understood as the senior+ swe mantra.

The SWEBOK, on the contrary, asserts "it does not depend" and that in a sense is the core problem.

For a detailed takedown, the ACM's is the most famous, there are others that v3 sparked. I'm sure v4 is sparking it's own detailed analysis ... I'm bowing out to go do my day job now. :)

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

#116
post #93

Earlier quoted context omitted.

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…

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 m…

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.

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

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

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.

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

#118
post #10

Earlier quoted context omitted.

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…

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…

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

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

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

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.

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

#120

Earlier quoted context omitted.

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 m…

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.

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.

Post reply on HN