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?
Runtime errors surface when a program
runs into an unexpected condition or situation
such as dividing by zero, memory overflow, or
addressing a wrong or unauthorized memory
location or device, or when a program tries to
perform an illegitimate or unauthorized operation
or tries to access a library, for example.
The programs must be thoroughly tested for
various types of inputs (valid data sets, invalid
data sets and boundary value data sets) and
conditions to identify these errors. Once identified,
runtime errors are easy to fix.
Embarrassing horseshit.Cook Ding was cutting up an ox for Lord Wenhui. As every touch of his hand, every heave of his shoulder, every move of his feet, every thrust of his knee — zip! zoop! He slithered the knife along with a zing, and all was in perfect rhythm, as though he were performing the dance of the Mulberry Grove or keeping time to the Jingshou music.
“Ah, this is marvelous!” said Lord Wenhui. “Imagine skill reaching such heights!”
Cook Ding laid down his knife and replied, “What I care about is the Way, which goes beyond skill. When I first began cutting up oxen, all I could see was the ox itself. After three years I no longer saw the whole ox. And now — now I go at it by spirit and don’t look with my eyes. Perception and understanding have come to a stop and spirit moves where it wants. I go along with the natural makeup, strike in the big hollows, guide the knife through the big openings, and following things as they are. So I never touch the smallest ligament or tendon, much less a main joint.
“A good cook changes his knife once a year — because he cuts. A mediocre cook changes his knife once a month — because he hacks. I’ve had this knife of mine for nineteen years and I’ve cut up thousands of oxen with it, and yet the blade is as good as though it had just come from the grindstone. There are spaces between the joints, and the blade of the knife has really no thickness. If you insert what has no thickness into such spaces, then there’s plenty of room — more than enough for the blade to play about it. That’s why after nineteen years the blade of my knife is still as good as when it first came from the grindstone.
“However, whenever I come to a complicated place, I size up the difficulties, tell myself to watch out and be careful, keep my eyes on what I’m doing, work very slowly, and move the knife with the greatest subtlety, until — flop! the whole thing comes apart like a clod of earth crumbling to the ground. I stand there holding the knife and look all around me, completely satisfied and reluctant to move on, and then I wipe off the knife and put it away.”
“Excellent!” said Lord Wenhui. “I have heard the words of Cook Ding and learned how to care for life!”
I had to open the PDF and find this line to confirm. It really says that. It reads as if claiming that any program that accesses a library will then have a runtime error. That is obviously not what they intended, but I have read it over a few times now and cannot see another interpretation.
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.
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.
$ ./main
./main: error while loading shared libraries: librandom.so: cannot open shared object file: No such file or directory
Which is indeed a runtime error.There is also the common use case of hot-reloading compiled code which dynamically loads and unloads shared libraries without restarting the entire application. It needs to be done carefully but you've likely used an application that does this. Failure to load a library, or loading an incompatible one will also create a runtime error.
Looks like there is a lot of bad generalizations in here, but they are technically correct on this one.
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?
for example:
or tries to access a library that it is unable to for some reason without handling the resulting error.
* 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.
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."
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 ;-)
Software engineering is programming professionally, with a dialogue on quality. Everything else is details.
The IEEE has been riding this horse for a very long time, in the face of very serious criticism (see the ACMs comments from a quarter century ago).
The presentation of it is _not even wrong_. It reads like a mid level manager at a very old enterprise firm wrote out what important at their firm, and took no material care for other ways. The SWEBOK has been that way for as long as I can remember ( an aside: my experience of Software Engineering academia has been so deeply negative to the point I wrote the field off in 2013. Decoupled from reality, PM oriented, toy studies- irrelevant. The SWEBOK is an artifact of that world. I should dip back in... Maybe Google & MS Research have done the real work here...)
There's a body of _practice_ that is mildly incidental. Most acronyms are fads. Lots of ephemeral technologies that only exist as painful grimaces. IE- CORBA- SOAP, etc...
Project management and quality management are also essentially contingent. One company does this. One that. Waterfall here. Agile there. Whirlpool the other.
What you're left with as non contingent and timeless is in the area of compilers, algorithms, etc. Which is not SWE at all.
If I were to write a swe body of knowledge, it would be in koan form, more than likely.
Please do! You can continue with standalone HN comments, which can be upvoted to enlighten human and AI bot alike.
Since when has anyone ever tried to pronounce 'GPS' as anything other than G-P-S? Also "ECS" = "Ecosystem"? Maybe I'm just crazy but I've never heard or read anyone abbreviate ecosystem as 'ECS'. I've come across ECS as entity component system in video game engines, but never as just 'ecosystem'. Also it's defined exactly once in chapter 5 and then never used again in the book. Why even bother to mention it then?
Oh and publish it as a PDF, but then have no actual page numbers?
Except for all those runtime errors where the fix required major refactoring, or the problem is in a third party library, the OS, or some other unchangeable component.
Well, there's your mistake right there. You're supposed to be riding an ox.
All this talk of oxen and horses got me curious about the PDF, so I went and took a look. It's really far worse than you've described.
I couldn't stomach it for too long, but here's some highlights:
(1) The first ~65 pages are about "requirements gathering." Page 60 offers up this gem of insight:
Priority = ((Value * (1 - Risk)) / Cost
(2) The next hundreds of pages go through topics in sequence, like "Architecture" and "Design" (who knew they were different?). Naturally, "Security" is slapped on several hundred pages later.I couldn't make it through the whole PDF, in all honesty. But I'm quite certain the soul of software engineering is nowhere to be found in there; they've eliminated it entirely and replaced it with stamp-collecting and checklists.
> 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?
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)
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 just to start a discussion and to be able to disagree on definitions and practices.
a word (such as NATO, radar, or laser) formed from the initial letter or letters of each of the successive parts or major parts of a compound term
also : an abbreviation (such as FBI) formed from initial letters : initialism
It appears the meaning of the word has changed over time.
Imagine instead it's for criminal defense lawyers: re-word it to be advice for attorneys defending their client against a prosecution. "Once [all exculpatory evidence against your client] is identified, defending them against a guilty verdict is easy to do"
It sounds like it's written by someone who has never practiced in the real world.
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.
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.
Civil and mechanical engineering are not static fields. They come up with new materials, new methods, new ideas. They have tooling to understand the impact of a proposed change and standard ways to test and validate things. It is much easier to predict how long it will take to both design and build things. These are all good things.
We would all benefit from fewer cryptoAI startups and frameworks of the week and more robust toolchains tested and evolved over 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.
It reminds me of the phrase "If all you have is a hammer, you tend to see every problem as a nail.." But in the case of a thick design patterns book, it amounts to giving the junior dev a whole toolbox... The junior dev tends to assume that every problem they'll ever face requires them to use one of the tools from that toolbox... But reality isn't so neat; you rarely use a specific tool in its native form as it's described. They are conceptual tools which need to be adapted to various situations and they are only really useful in highly complex scenarios which can often be avoided entirely.
The one piece of advice which is closest to 'universal' which I can give about software development is this:
"You should be able to walk through and describe any feature provided by your code using plain English, in such a way that a non-technical listener would gain a complete understanding of what the code is doing but without having to dive into functions whose implementation details would exceed the listener's mental capabilities."
When someone talks me through some feature they developed and they start jumping around 10 different files 80% of which have technical names which they invented and they keep having to define new concepts just to explain what the code is doing at a high level; this is a red flag. It shows that their code is over-engineered and that they haven't fully made sense of what they're doing in their own mind.
My philosophy is basically a variant of "Rubber duck debugging" as proposed in the book "The Pragmatic Programmer" by Andrew Hunt and David Thomas... But you imagine the duck to have the intellect and knowledge of a non-technical middle-manager, and you use the approach during design and development; not just debugging.
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.
(Freely available in the same sense that the SWEBOK is I mean; you can read it free of charge without DRM and without having to resort to piracy. Doesn't have to be a fully free book that goes as far as to allow modification and redistribution although that is an extra nice bonus if any of your suggested books are like that.)
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.
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 though
There are way too many software engineers with lofty ideas about how physical engineers can magically know all the answers to all the problems they could ever have.
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?
1- very heavy on process management. Not against studying it, but 70% is a lot. Also it isn't a very objective area of knowledge, there's hundreds of ways to skin the pig, which probably explains why it takes so much space.
2- a whole chapter about architecture, which isn't a very well regarded as an independent branch of computer science/systems engineering knowledge.
3- at last, in the technical section, databases shares a section along with fundamentals like processes and operating systems?
All in all it looks like a dictionary/checkbox built by a comittee rather than a consistent perspective on software.
And as a textbook it's got problems as well as mentioned, it has a doubtful taxonomy and too heavy on process engineering.
Tl;dr: I'm getting Orange Eating 101 vibes https://youtu.be/pR6z-gm5_cY?t=38&si=F7knCRNcFET7nki7
Anyways, my 2 cents, won't be reading it.
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.
> 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.
2022.
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.
It is useless because no one will read it or use it as any type of benchmark, probably rightly so here. There is a version of this at every company, just more relevant, also already not being read of course.
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.
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.
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.
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.
https://www.goodreads.com/list/show/121496.SWEBOK_Consolidat...
Choosing a dead document or "mostly dead" if we're generous (with a new version every decade) for a body of knowledge that is constantly growing and developing makes no sense. If you want to publish it as a PDF that's ok, but it needs continuous updates, not decadal updates.
In 2014 Agile barely got a passing mention in the book, 13 years after the term had come into existence and a decade after it had already made major waves in software engineering (many of the concepts that fell under Agile were also already published in the 1990s or earlier and barely mentioned or not mentioned). OOP gets a more substantive section in the 2024 version than the 2014 version when OOP languages had been out for decades before the 2014 one was published. In their added chapter on security they don't even have references for any of section 6.
All of these are things that can be addressed by making it a living document. Update it more regularly so it's actually relevant instead of catching up on ideas from 2009 in 2024 (DevOps as a term dates at least back that far) or ideas from the 1960s and 1970s (OOP) in 2024.
Practitioners are better off reading Wikipedia than this document. It's more comprehensive, more up to date, and has more references they can use to follow up on topics than this book does.
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.
You do not need a credential to work on EV charging infrastructure, rockets, crew capsules to ferry astronauts to the ISS, or many, many other things.
That's how you know, because those fields are not less safe. It's an easy comparison.
The IEEE has been a worn-out, irrelevant relic of the past for at least 2 decades now.
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.
The hardest for me to accept is the loss of alternate. It now means the same thing as alternative, but it used to refer to switching between possible states, usually in an oscillating manner. Nowadays I alternate between caring and not caring.
But the part of "how to manage the process of creating this" and related ideas you were basically supposed to figure out on your own. Or actively ask the teachers. It feels very sink-or-swim now in retrospect. I've never been explicitly taught about testing for example, but if you didn't write them for your projects, I don't think you'd complete them.
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.