6 ms·

There appears to be a lot of hate towards this in the comments (because it's not perfect?), but I feel strongly that we need explicit bodies of knowledge, along

There appears to be a lot of hate towards this in the comments (because it's not perfect?), but I feel strongly that we need explicit bodies of knowledge, along with certifications for having been trained on it. Every company I go to, the base of knowledge of all the engineers is a complete crapshoot. Most of them lack fundamental knowledge about software engineering. And they all lack fundamental knowledge about the processes used to do the work. That's not how engineering should work. If I hire an architect, I shouldn't have to quiz them to find out if they understand Young's Modulus, much less teach them about it on the job. But that's completely normal in software engineering today, because nobody is expected to have already learned a universal body of knowledge. I get this thing isn't perfect. But not being perfect isn't a rational argument for not having one at all. And we certainly need to hold people accountable to have learned it before we give them a job. We need a body of knowledge, it needs to be up to date and relevant, and we need to prove people have actually read it and understood it. If this isn't it, fine, but we still need one. (this is, by the way, kind of the whole fucking point of a trade school and professional licensing... why the fuck we don't have one for software engineers/IT, boggles my fucking mind, if this is supposed to be the future of work)

abtinf 2y ago
> if this is supposed to be the future of work The day computing becomes subject to professional licensure is the day the field of computing will fall into hopeless stagnation, just like every other such field.
- lotsoweiners 2y ago
  Maybe that’s not a bad thing…
  - rockemsockem 2y ago
    Let me hear your pro-stagnation argument
    - lantry 2y ago
      Here's my "pro-stagnation" argument: stagnation and stability are pretty much the same thing. There's a lot of infrastructure that we take for granted because it always works (water purification and distribution, bridges and roads, electrical generation and transmission, automobile engines, the quality of gasoline, the safety of food, etc). You trust that these things will work the way you expect, because they don't change very quickly. Is that stagnation or stability?
      - rockemsockem 2y ago
        So I don't know about you, but I live in America where roads, electrical generation and transmission, water purification, and bridges are all in subpar shape. That's super broad and I think there are complex reasons why each of these has failed, but it's pretty clear that stagnation hasn't helped and has probably actively caused harm by letting incompetence become too common in these areas.
        patmorgan23 2y ago
        This is just not the case. The US has lots of infrastructure that needs repair or replacement, but there are very few areas that do not have clean water, or reliable electricity (Sans extreme weather which causes disruptions in every country), and roads and bridges are all safe to drive on (when was the last time you read about a bridge that collapsed from lack of maintenance?) The US has its issues, but it does actually have a huge amount of superb, world class infrastructure.
        Jtsummers 2y ago
        > when was the last time you read about a bridge that collapsed from lack of maintenance? 2022. https://en.wikipedia.org/wiki/Fern_Hollow_Bridge https://en.wikipedia.org/wiki/Fern_Hollow_Bridge
        shiroiushi 2y ago
        >reliable electricity (Sans extreme weather which causes disruptions in every country) Freezing temperatures do not cause widespread outages in properly-run countries. >roads and bridges are all safe to drive on (when was the last time you read about a bridge that collapsed from lack of maintenance?) 2022, when the President was in town in Pittsburg and the bridge there collapsed.
rockemsockem 2y ago
Every time I see someone post this line of reasoning they talk like this, as if other engineering disciplines all have some cert that is the god-tier cert. While this is true for some engineering fields it's mostly not true and I think that's a good thing because credentialism is bad actually. Also, architects are not even engineers.
- Arainach 2y ago
  Credentialism is good. It provides both a trustworthy reference point and a method for punishment. If I want someone to do work, I want them to be licensed/certified. If they are flagrantly unsafe, I want a licensing board or similar to be able to strip that person of their ability to practice that profession. This raises public perception of the profession as a while, avoids a market for lemons, and gives some baseline. There are too many decisions in life to be able to spend an hour (or more) researching every option. Credentials allow a framework of trust - I don't have to decide if I trust every single engineer; if they have passed their PE exam and not had their certification taken away that is a starting point.
  - rockemsockem 2y ago
    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 many places to rely solely on the credentials, which are obviously never sufficient to find high quality individuals. What are the jobs you're day dreaming about that require PE exams? I'd bet that requirement is much less common than you think.
    - Arainach 2y ago
      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.
eacapeisfutuile 2y ago
> Every company I go to, the base of knowledge of all the engineers is a complete crapshoot Sounds like unfortunate companies to go to. > much less teach them about it on the job That is literally how and where people learn the job pretty much everywhere. > it needs to be up to date Yeah, it will never be. > we need to prove people have actually read it and understood it Why/how?
- Jtsummers 2y ago
  >> it needs to be up to date > Yeah, it will never be. And this particular document will never be up to date. SWEBOK gets updated on the order of every 5-10 years, so it's always going to be dated. This is one reason it's a poor document for its purpose. If they want it to be relevant it needs to be continuously developed and updated. Hire active editors for the different "knowledge areas" (consider even losing that notion, it's very CMMI which is not something to aspire to) and solicit contributions from practitioners to continuously add to, remove from, correct, and amend the different sections. Build out the document they actually want instead of wasting 5-10 years publishing an updated, but still out-of-date, document.
  - nradov 2y ago
    I think you missed the purpose of the SWEBOK. It is intended to cover basic fundamentals which don't change much decade by decade. Not the latest JavaScript framework or whatever. Just about everything in the previous version from 2014 is still relevant today.
    - eacapeisfutuile 2y ago
      That made me curious, is there a changelog somewhere on changes between editions?
      - Jtsummers 2y ago
        https://www.computer.org/education/bodies-of-knowledge/software-engineering https://www.computer.org/education/bodies-of-knowledge/softw... - shows a comparison of the TOCs of version 3 (2014) and version 4 (2024). Dates emphasized for my point, it's a decade apart. In 10 years they added 3 chapters and references to DevOps and Agile.
pnathan 2y ago
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. It confuses SWE with PM, badly. And it has done so, historically. To the point of wide condemnation.
- nradov 2y ago
  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 order to make competent engineering decisions you have to understand how your tasks fit into the whole.
  - pnathan 2y ago
    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. :)
    - saulpw 2y ago
      I cannot find this "ACM's detailed takedown of the SWEBOK", could you provide a better reference? edit: found it: https://web.archive.org/web/20000815071233/http://www.acm.org/serving/se_policy/bok_assessment.pdf https://web.archive.org/web/20000815071233/http://www.acm.or...
  - kragen 2y ago
    A comprehensive list of the SWEBOK's problems would run to tens of thousands of pages, so it will surely never be written. But here's a summary of my own comments in this thread on the topic. I think they cover most of the important aspects. As its Introduction clearly explains, the SWEBOK is primarily a work of political advocacy. One of its political goals is a particular division of labor in software that has been tried, has failed, and has largely been abandoned, as I explained in https://news.ycombinator.com/item?id=41918800 https://news.ycombinator.com/item?id=41918800. It also advocates basing that division of labor on a form of credentialism which has also been tried in software and continues to fail, as I explained in https://news.ycombinator.com/item?id=41931336 https://news.ycombinator.com/item?id=41931336. As explained in https://news.ycombinator.com/item?id=41907822 https://news.ycombinator.com/item?id=41907822, the ACM canceled their involvement in the SWEBOK effort in part because they are opposed to this political program, leaving it entirely in the hands of the IEEE. Unfortunately, today's IEEE seemingly lacks the technical competence at an organizational level to avoid publishing utter nonsense through many channels. (Many IEEE members are of course highly knowledgeable, but evidently they aren't the ones in charge.) As a result, the substantive content of the SWEBOK is also riddled with astoundingly incompetent errors; I dissected a representative paragraph in https://news.ycombinator.com/item?id=41915939 https://news.ycombinator.com/item?id=41915939, finding 12 serious factual errors in 86 words. As is commonly the case with text written with no concern for veracity, it takes roughly 20 times as much text to correct the errors as it did to make them. The content of the SWEBOK that actually concerns the engineering of software is not just as error-riddled as the rest of it, but also very limited†, displaced by project-management information, as I showed with a random sampling in https://news.ycombinator.com/item?id=41916612 https://news.ycombinator.com/item?id=41916612. This focus would represent a major departure from accredited curricula in real engineering‡ fields such as mechanical engineering, chemical engineering, and electrical engineering, as I showed by surveying top university curricula in those fields in https://news.ycombinator.com/item?id=41918011 https://news.ycombinator.com/item?id=41918011. The SWEBOK represents an attempt to substitute management process for technical knowledge, an approach which is well known not to work. This is what Dijkstra was criticizing about the so-called "software engineering" field 35 years ago in EWD1036, which I linked from the third comment of mine linked above. (Unlike Dijkstra, I do not think that it is futile to apply an engineering approach to software, but that is not what studying project management is.) Even within the scope of project management knowledge, the SWEBOK primarily advocates the kinds of management approaches that work well in industries such as mining and civil engineering. However, as I explained in https://news.ycombinator.com/item?id=41914610 https://news.ycombinator.com/item?id=41914610, fundamental differences between those fields and the engineering of software make those management approaches a recipe for failure in software, even with ample engineering competence. Engineering is a craft based on science, using formalized theory to navigate tradeoffs to solve problems despite great intellectual difficulty. But, as I explained in https://news.ycombinator.com/item?id=41914332 https://news.ycombinator.com/item?id=41914332, our current formal theory of software is not strong enough to provide much help with that task. That does not mean that teaching people how to engineer software is hopeless; in that comment I outlined a general approach, and in https://news.ycombinator.com/item?id=41918787 https://news.ycombinator.com/item?id=41918787 I give more details about the specific things people engineering software need to know, which has relatively little overlap with the SWEBOK. This current state of theoretical knowledge means that you cannot meaningfully assess software engineers' competence by testing their mastery of formal theory, because the formal theory we have is only somewhat relevant to actually engineering software. Instead, you must observe them attempting to engineer some software. That is why credentialism is so especially counterproductive in this field. That would still be a fatal flaw in the SWEBOK even if its content were primarily focused on the actual engineering of software rather than project management. As I said in https://news.ycombinator.com/item?id=41914444 https://news.ycombinator.com/item?id=41914444, the health-care equivalent of the approach advocated by the SWEBOK is faith healing; the agricultural equivalent of the approach advocated by the SWEBOK was the Great Leap Forward; and the petroleum-exploration equivalent of the approach advocated by the SWEBOK is dowsing. ______ † "The food here is terrible! And such small portions!" ‡ The engineering of software is real engineering, as Hillel Wayne convincingly demonstrated in https://www.hillelwayne.com/talks/crossover-project/ https://www.hillelwayne.com/talks/crossover-project/, but this is still a controversial point. So I picked three fields which I hope everyone can agree are real engineering. The "software engineering" that the SWEBOK is about, and that Dijkstra was criticizing, is not the engineering of software and is not in fact engineering at all.
creer 2y ago
You are under this illusion about other fields like architects because you don't work there and you can't tell. You don't know how the sausage is made. Historically I have tended to learn about a new field WAY too much before I tried to hire people in these fields. The truth is, that makes it hard to hire people (but for good reason - depending on your needs, you need to pass on a lot of people). More recently I have tried to pay very close attention to how people do their work (about whose field I am building an interest). The sad reality of the world is that most people and businesses stay in business entirely through dumb luck and because the world is not usually THAT demanding. And if you have a specific requirement, they won't be able to help "out of the box". You are imagining this competence. It doesn't exist in most people. And to compound this, to me, the characteristic of an engineer is that they are capable of learning about a specialty discipline. If you hire an engineer and they are incapable of learning something that's needed in your project, THAT is where their problem is (and yours for not hiring to that.) Engineering is not a trade. Certifications are usually about selling them or gatekeeping. I wish it were possible to certify "engineering progress mindset" - no, it doesn't have an ISO number.
- 0xbadcafebee 2y ago
  On the contrary, I am fully aware that there exists no field where a test or piece of paper guarantees excellence. But I am also aware what the lack of it does. It leads to buildings falling down or burning up [with people in them]. This was a common occurrence 100+ years ago. You know what made it less common? Standardization. Building codes. Minimum standards for engineers and the trades. Independent studies have all concluded that real world outcomes improved across the board because of these things. No formal certification or standard will lead to perfection. That is obvious. But what is also obvious, from actually looking at outcomes before and after their introduction, is that having them leads to better outcomes. You have to stop thinking about individual engineers, and start thinking about the much, much larger picture. What changes will have a positive effect on the larger picture? You can only have an effect on the larger picture if you enforce a change across the board, and then look at the aggregate results. That can not happen without a mechanism to enforce the change. We can't pray our way to better results, or just sit around hoping people magically get better at their jobs, because that clearly has not happened for the last few decades that I've been working. The more we depend on technology, the more we see the failures of a lack of rigor. Probably every single person with an address and social security number in the United States has had their personal information leaked, multiple times over, by now. Lives are ruined by systems that do not take into consideration the consequences of a lack of safety, or the bias of its creators. Entire global transportation systems are shut down because nobody added basic tests or fail-safes to critical software infrastructure. This shit isn't rocket science, man. It was all preventable. And just like with building codes, standards, licenses, etc, we can put things in place to actually teach people the right way to do things, and actually check for the preventable things, by law. If we don't, it's going to keep happening, and keep happening, and keep happening, and keep happening, forever. We can do something to stop it. But we have to pound our fist on the desk and say, enough is enough. We have to put something imperfect in place to stem the tide of enshittification. Because there are consequences if we don't. We have seen some of them globally in the form of warfare, but nothing compared to the devastation when the gloves come off. We have not yet seen an entire country's hacker resources attack the water, power, sanitation, food, and other systems of its enemy, all at once. But it's going to happen. And it's going to be devastating. Millions of people are going to die because some asshole set a default password on some SCADA systems. But it should have been impossible, because no SCADA system should be allowed to be sold with default passwords. That's the kind of thing we can prevent, just like you can't build a building today without a fire exit. That's the really big obvious impact. The impact nobody sees are from tiny decisions all the time, that slowly affect a few people at a time, but on the scale of millions of businesses and billions of people, add up to really big effects. We can make a huge difference here too, which will only be visible in aggregate later on. Like public sanitation, clean water, or hand-washing with soap, nobody thinks about the dramatic effect on public health and longevity until it's clear after decades what kind of impact it made. Technology is everywhere, in every home, affecting every life. The more we improve it [as a standard], the more we will see huge positive impacts later.
osigurdson 2y ago
What are you hoping professional licensing might do for you? I can attest that outside of traditional engineering fields, licensing is completely useless and confers roughly the same level of prestige as a Costco membership. I'll send you my engineering ring in the mail if you like (Canada's cheesy contribution to engineering culture).
globular-toast 2y ago
I completely agree. The trouble is we're so far away from this that all the people who learnt from a few tutorials and never read any books will try to defeat it at every step. They're here in these very comments. I get that it's possible to build working software without a certificate, in much the same way as someone can do their own electrics. But is it up to standard and safe for the next guy to work on? This is why we have standards.
yowlingcat 2y ago
> I feel strongly that we need explicit bodies of knowledge, along with certifications for having been trained on it. ... > That's not how engineering should work. If I hire an architect, I shouldn't have to quiz them to find out if they understand Young's Modulus Why do you feel strongly about it? Why isn't that how software engineering should work? While I don't disagree with your belief that improved software engineering skill foundations would be better for the industry as a whole, I find your conclusion unpersuasive because it seems to imply that "something is better than nothing." But as this sibling comments alludes to (an ACM rebuttal to SWEBOK): https://news.ycombinator.com/item?id=41907822 https://news.ycombinator.com/item?id=41907822 https://web.archive.org/web/20000815071233/http://www.acm.org/serving/se_policy/bok_assessment.pdf https://web.archive.org/web/20000815071233/http://www.acm.or... I find the ACM's argument more persuasive: ``` The SWEBOK effort uses the notion of “generally accepted knowledge” as a cornerstone, specifically excluding “practices used only for specific types of software.” We believe very strongly that, for software, this is approach is highly likely to fail and that the opposite approach — primarily focusing on specific domains — is far more likely to succeed. The central reason is that software engineering addresses a much broader scope than traditional engineering disciplines. ... ``` And I tend to agree with their conclusion: ``` Overall, our assessment has led us to the conclusion that the SWEBOK effort is geared aggressively towards trying to define an overall level of professional practice for all of software engineering that would implicitly provide assurances to the public. Furthermore, we believe strongly that it will fail to lead to an achievable level of professional practice in a reasonable time and that, in failing, it may lead to a situation in which the public is provided with false assurances of the quality of software systems ... ``` To conclude, I'll address a point you raised which I have a hunch could be the root premise of your argument: > Every company I go to, the base of knowledge of all the engineers is a complete crapshoot. Most of them lack fundamental knowledge... If this is what you've seen at every company you go to, it could be that the common thread is you. I've worked at a variety of companies over my career, and quite a few suffered from the issue you mention. But on the whole, at least half of them (and by proxy, the engineers and engineering orgs I've worked in) have been the exact opposite. The technical bar is very high, the body of knowledge is established, clearly defined, and rigorously enforced; in doing so, these organizations were able to ship durable, high quality code with high velocity and a low defect rate even as the business expanded dramatically and we experienced setbacks and false starts. While I don't think my experience is universal, I also don't think it's unique either. My unsolicited advice to you would be to try and find a company that has the technical bar you would like to see and work there for a while. Failure is a much poorer teacher than success. There is certainly room for software engineering to evolve as a practice, but for the aforementioned reasons (articulated by folks in far greater, well thought through detail than I have), I don't believe SWEBOK holds the keys.

abtinf 2y ago

> if this is supposed to be the future of work The day computing becomes subject to professional licensure is the day the field of computing will fall into hopeless stagnation, just like every other such field.

lotsoweiners 2y ago
Maybe that’s not a bad thing…
- rockemsockem 2y ago
  Let me hear your pro-stagnation argument
  - lantry 2y ago
    Here's my "pro-stagnation" argument: stagnation and stability are pretty much the same thing. There's a lot of infrastructure that we take for granted because it always works (water purification and distribution, bridges and roads, electrical generation and transmission, automobile engines, the quality of gasoline, the safety of food, etc). You trust that these things will work the way you expect, because they don't change very quickly. Is that stagnation or stability?
    - rockemsockem 2y ago
      So I don't know about you, but I live in America where roads, electrical generation and transmission, water purification, and bridges are all in subpar shape. That's super broad and I think there are complex reasons why each of these has failed, but it's pretty clear that stagnation hasn't helped and has probably actively caused harm by letting incompetence become too common in these areas.
      - patmorgan23 2y ago
        This is just not the case. The US has lots of infrastructure that needs repair or replacement, but there are very few areas that do not have clean water, or reliable electricity (Sans extreme weather which causes disruptions in every country), and roads and bridges are all safe to drive on (when was the last time you read about a bridge that collapsed from lack of maintenance?) The US has its issues, but it does actually have a huge amount of superb, world class infrastructure.
        Jtsummers 2y ago
        > when was the last time you read about a bridge that collapsed from lack of maintenance? 2022. https://en.wikipedia.org/wiki/Fern_Hollow_Bridge https://en.wikipedia.org/wiki/Fern_Hollow_Bridge
        shiroiushi 2y ago
        >reliable electricity (Sans extreme weather which causes disruptions in every country) Freezing temperatures do not cause widespread outages in properly-run countries. >roads and bridges are all safe to drive on (when was the last time you read about a bridge that collapsed from lack of maintenance?) 2022, when the President was in town in Pittsburg and the bridge there collapsed.

rockemsockem 2y ago

Every time I see someone post this line of reasoning they talk like this, as if other engineering disciplines all have some cert that is the god-tier cert. While this is true for some engineering fields it's mostly not true and I think that's a good thing because credentialism is bad actually. Also, architects are not even engineers.

Arainach 2y ago
Credentialism is good. It provides both a trustworthy reference point and a method for punishment. If I want someone to do work, I want them to be licensed/certified. If they are flagrantly unsafe, I want a licensing board or similar to be able to strip that person of their ability to practice that profession. This raises public perception of the profession as a while, avoids a market for lemons, and gives some baseline. There are too many decisions in life to be able to spend an hour (or more) researching every option. Credentials allow a framework of trust - I don't have to decide if I trust every single engineer; if they have passed their PE exam and not had their certification taken away that is a starting point.
- rockemsockem 2y ago
  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 many places to rely solely on the credentials, which are obviously never sufficient to find high quality individuals. What are the jobs you're day dreaming about that require PE exams? I'd bet that requirement is much less common than you think.
  - Arainach 2y ago
    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.

eacapeisfutuile 2y ago

> Every company I go to, the base of knowledge of all the engineers is a complete crapshoot Sounds like unfortunate companies to go to. > much less teach them about it on the job That is literally how and where people learn the job pretty much everywhere. > it needs to be up to date Yeah, it will never be. > we need to prove people have actually read it and understood it Why/how?

Jtsummers 2y ago
>> it needs to be up to date > Yeah, it will never be. And this particular document will never be up to date. SWEBOK gets updated on the order of every 5-10 years, so it's always going to be dated. This is one reason it's a poor document for its purpose. If they want it to be relevant it needs to be continuously developed and updated. Hire active editors for the different "knowledge areas" (consider even losing that notion, it's very CMMI which is not something to aspire to) and solicit contributions from practitioners to continuously add to, remove from, correct, and amend the different sections. Build out the document they actually want instead of wasting 5-10 years publishing an updated, but still out-of-date, document.
- nradov 2y ago
  I think you missed the purpose of the SWEBOK. It is intended to cover basic fundamentals which don't change much decade by decade. Not the latest JavaScript framework or whatever. Just about everything in the previous version from 2014 is still relevant today.
  - eacapeisfutuile 2y ago
    That made me curious, is there a changelog somewhere on changes between editions?
    - Jtsummers 2y ago
      https://www.computer.org/education/bodies-of-knowledge/software-engineering https://www.computer.org/education/bodies-of-knowledge/softw... - shows a comparison of the TOCs of version 3 (2014) and version 4 (2024). Dates emphasized for my point, it's a decade apart. In 10 years they added 3 chapters and references to DevOps and Agile.

pnathan 2y ago

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. It confuses SWE with PM, badly. And it has done so, historically. To the point of wide condemnation.

nradov 2y ago
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 order to make competent engineering decisions you have to understand how your tasks fit into the whole.
- pnathan 2y ago
  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. :)
  - saulpw 2y ago
    I cannot find this "ACM's detailed takedown of the SWEBOK", could you provide a better reference? edit: found it: https://web.archive.org/web/20000815071233/http://www.acm.org/serving/se_policy/bok_assessment.pdf https://web.archive.org/web/20000815071233/http://www.acm.or...
- kragen 2y ago
  A comprehensive list of the SWEBOK's problems would run to tens of thousands of pages, so it will surely never be written. But here's a summary of my own comments in this thread on the topic. I think they cover most of the important aspects. As its Introduction clearly explains, the SWEBOK is primarily a work of political advocacy. One of its political goals is a particular division of labor in software that has been tried, has failed, and has largely been abandoned, as I explained in https://news.ycombinator.com/item?id=41918800 https://news.ycombinator.com/item?id=41918800. It also advocates basing that division of labor on a form of credentialism which has also been tried in software and continues to fail, as I explained in https://news.ycombinator.com/item?id=41931336 https://news.ycombinator.com/item?id=41931336. As explained in https://news.ycombinator.com/item?id=41907822 https://news.ycombinator.com/item?id=41907822, the ACM canceled their involvement in the SWEBOK effort in part because they are opposed to this political program, leaving it entirely in the hands of the IEEE. Unfortunately, today's IEEE seemingly lacks the technical competence at an organizational level to avoid publishing utter nonsense through many channels. (Many IEEE members are of course highly knowledgeable, but evidently they aren't the ones in charge.) As a result, the substantive content of the SWEBOK is also riddled with astoundingly incompetent errors; I dissected a representative paragraph in https://news.ycombinator.com/item?id=41915939 https://news.ycombinator.com/item?id=41915939, finding 12 serious factual errors in 86 words. As is commonly the case with text written with no concern for veracity, it takes roughly 20 times as much text to correct the errors as it did to make them. The content of the SWEBOK that actually concerns the engineering of software is not just as error-riddled as the rest of it, but also very limited†, displaced by project-management information, as I showed with a random sampling in https://news.ycombinator.com/item?id=41916612 https://news.ycombinator.com/item?id=41916612. This focus would represent a major departure from accredited curricula in real engineering‡ fields such as mechanical engineering, chemical engineering, and electrical engineering, as I showed by surveying top university curricula in those fields in https://news.ycombinator.com/item?id=41918011 https://news.ycombinator.com/item?id=41918011. The SWEBOK represents an attempt to substitute management process for technical knowledge, an approach which is well known not to work. This is what Dijkstra was criticizing about the so-called "software engineering" field 35 years ago in EWD1036, which I linked from the third comment of mine linked above. (Unlike Dijkstra, I do not think that it is futile to apply an engineering approach to software, but that is not what studying project management is.) Even within the scope of project management knowledge, the SWEBOK primarily advocates the kinds of management approaches that work well in industries such as mining and civil engineering. However, as I explained in https://news.ycombinator.com/item?id=41914610 https://news.ycombinator.com/item?id=41914610, fundamental differences between those fields and the engineering of software make those management approaches a recipe for failure in software, even with ample engineering competence. Engineering is a craft based on science, using formalized theory to navigate tradeoffs to solve problems despite great intellectual difficulty. But, as I explained in https://news.ycombinator.com/item?id=41914332 https://news.ycombinator.com/item?id=41914332, our current formal theory of software is not strong enough to provide much help with that task. That does not mean that teaching people how to engineer software is hopeless; in that comment I outlined a general approach, and in https://news.ycombinator.com/item?id=41918787 https://news.ycombinator.com/item?id=41918787 I give more details about the specific things people engineering software need to know, which has relatively little overlap with the SWEBOK. This current state of theoretical knowledge means that you cannot meaningfully assess software engineers' competence by testing their mastery of formal theory, because the formal theory we have is only somewhat relevant to actually engineering software. Instead, you must observe them attempting to engineer some software. That is why credentialism is so especially counterproductive in this field. That would still be a fatal flaw in the SWEBOK even if its content were primarily focused on the actual engineering of software rather than project management. As I said in https://news.ycombinator.com/item?id=41914444 https://news.ycombinator.com/item?id=41914444, the health-care equivalent of the approach advocated by the SWEBOK is faith healing; the agricultural equivalent of the approach advocated by the SWEBOK was the Great Leap Forward; and the petroleum-exploration equivalent of the approach advocated by the SWEBOK is dowsing. ______ † "The food here is terrible! And such small portions!" ‡ The engineering of software is real engineering, as Hillel Wayne convincingly demonstrated in https://www.hillelwayne.com/talks/crossover-project/ https://www.hillelwayne.com/talks/crossover-project/, but this is still a controversial point. So I picked three fields which I hope everyone can agree are real engineering. The "software engineering" that the SWEBOK is about, and that Dijkstra was criticizing, is not the engineering of software and is not in fact engineering at all.

creer 2y ago

You are under this illusion about other fields like architects because you don't work there and you can't tell. You don't know how the sausage is made. Historically I have tended to learn about a new field WAY too much before I tried to hire people in these fields. The truth is, that makes it hard to hire people (but for good reason - depending on your needs, you need to pass on a lot of people). More recently I have tried to pay very close attention to how people do their work (about whose field I am building an interest). The sad reality of the world is that most people and businesses stay in business entirely through dumb luck and because the world is not usually THAT demanding. And if you have a specific requirement, they won't be able to help "out of the box". You are imagining this competence. It doesn't exist in most people. And to compound this, to me, the characteristic of an engineer is that they are capable of learning about a specialty discipline. If you hire an engineer and they are incapable of learning something that's needed in your project, THAT is where their problem is (and yours for not hiring to that.) Engineering is not a trade. Certifications are usually about selling them or gatekeeping. I wish it were possible to certify "engineering progress mindset" - no, it doesn't have an ISO number.

0xbadcafebee 2y ago
On the contrary, I am fully aware that there exists no field where a test or piece of paper guarantees excellence. But I am also aware what the lack of it does. It leads to buildings falling down or burning up [with people in them]. This was a common occurrence 100+ years ago. You know what made it less common? Standardization. Building codes. Minimum standards for engineers and the trades. Independent studies have all concluded that real world outcomes improved across the board because of these things. No formal certification or standard will lead to perfection. That is obvious. But what is also obvious, from actually looking at outcomes before and after their introduction, is that having them leads to better outcomes. You have to stop thinking about individual engineers, and start thinking about the much, much larger picture. What changes will have a positive effect on the larger picture? You can only have an effect on the larger picture if you enforce a change across the board, and then look at the aggregate results. That can not happen without a mechanism to enforce the change. We can't pray our way to better results, or just sit around hoping people magically get better at their jobs, because that clearly has not happened for the last few decades that I've been working. The more we depend on technology, the more we see the failures of a lack of rigor. Probably every single person with an address and social security number in the United States has had their personal information leaked, multiple times over, by now. Lives are ruined by systems that do not take into consideration the consequences of a lack of safety, or the bias of its creators. Entire global transportation systems are shut down because nobody added basic tests or fail-safes to critical software infrastructure. This shit isn't rocket science, man. It was all preventable. And just like with building codes, standards, licenses, etc, we can put things in place to actually teach people the right way to do things, and actually check for the preventable things, by law. If we don't, it's going to keep happening, and keep happening, and keep happening, and keep happening, forever. We can do something to stop it. But we have to pound our fist on the desk and say, enough is enough. We have to put something imperfect in place to stem the tide of enshittification. Because there are consequences if we don't. We have seen some of them globally in the form of warfare, but nothing compared to the devastation when the gloves come off. We have not yet seen an entire country's hacker resources attack the water, power, sanitation, food, and other systems of its enemy, all at once. But it's going to happen. And it's going to be devastating. Millions of people are going to die because some asshole set a default password on some SCADA systems. But it should have been impossible, because no SCADA system should be allowed to be sold with default passwords. That's the kind of thing we can prevent, just like you can't build a building today without a fire exit. That's the really big obvious impact. The impact nobody sees are from tiny decisions all the time, that slowly affect a few people at a time, but on the scale of millions of businesses and billions of people, add up to really big effects. We can make a huge difference here too, which will only be visible in aggregate later on. Like public sanitation, clean water, or hand-washing with soap, nobody thinks about the dramatic effect on public health and longevity until it's clear after decades what kind of impact it made. Technology is everywhere, in every home, affecting every life. The more we improve it [as a standard], the more we will see huge positive impacts later.

osigurdson 2y ago

What are you hoping professional licensing might do for you? I can attest that outside of traditional engineering fields, licensing is completely useless and confers roughly the same level of prestige as a Costco membership. I'll send you my engineering ring in the mail if you like (Canada's cheesy contribution to engineering culture).

globular-toast 2y ago

I completely agree. The trouble is we're so far away from this that all the people who learnt from a few tutorials and never read any books will try to defeat it at every step. They're here in these very comments. I get that it's possible to build working software without a certificate, in much the same way as someone can do their own electrics. But is it up to standard and safe for the next guy to work on? This is why we have standards.

yowlingcat 2y ago

> I feel strongly that we need explicit bodies of knowledge, along with certifications for having been trained on it. ... > That's not how engineering should work. If I hire an architect, I shouldn't have to quiz them to find out if they understand Young's Modulus Why do you feel strongly about it? Why isn't that how software engineering should work? While I don't disagree with your belief that improved software engineering skill foundations would be better for the industry as a whole, I find your conclusion unpersuasive because it seems to imply that "something is better than nothing." But as this sibling comments alludes to (an ACM rebuttal to SWEBOK): https://news.ycombinator.com/item?id=41907822 https://news.ycombinator.com/item?id=41907822 https://web.archive.org/web/20000815071233/http://www.acm.org/serving/se_policy/bok_assessment.pdf https://web.archive.org/web/20000815071233/http://www.acm.or... I find the ACM's argument more persuasive: ``` The SWEBOK effort uses the notion of “generally accepted knowledge” as a cornerstone, specifically excluding “practices used only for specific types of software.” We believe very strongly that, for software, this is approach is highly likely to fail and that the opposite approach — primarily focusing on specific domains — is far more likely to succeed. The central reason is that software engineering addresses a much broader scope than traditional engineering disciplines. ... ``` And I tend to agree with their conclusion: ``` Overall, our assessment has led us to the conclusion that the SWEBOK effort is geared aggressively towards trying to define an overall level of professional practice for all of software engineering that would implicitly provide assurances to the public. Furthermore, we believe strongly that it will fail to lead to an achievable level of professional practice in a reasonable time and that, in failing, it may lead to a situation in which the public is provided with false assurances of the quality of software systems ... ``` To conclude, I'll address a point you raised which I have a hunch could be the root premise of your argument: > Every company I go to, the base of knowledge of all the engineers is a complete crapshoot. Most of them lack fundamental knowledge... If this is what you've seen at every company you go to, it could be that the common thread is you. I've worked at a variety of companies over my career, and quite a few suffered from the issue you mention. But on the whole, at least half of them (and by proxy, the engineers and engineering orgs I've worked in) have been the exact opposite. The technical bar is very high, the body of knowledge is established, clearly defined, and rigorously enforced; in doing so, these organizations were able to ship durable, high quality code with high velocity and a low defect rate even as the business expanded dramatically and we experienced setbacks and false starts. While I don't think my experience is universal, I also don't think it's unique either. My unsolicited advice to you would be to try and find a company that has the technical bar you would like to see and work there for a while. Failure is a much poorer teacher than success. There is certainly room for software engineering to evolve as a practice, but for the aforementioned reasons (articulated by folks in far greater, well thought through detail than I have), I don't believe SWEBOK holds the keys.