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)
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
> 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):
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.
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'm convinced slowing feeding students, and having them produce good low-level codebase(s) (e.g. OSs, compilers) is a great Way to "holistically" teach them CS, much better than what's happening usually. "C is a razor-sharp tool"!
The Master might say something like this, if translated crudely -
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.
> The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), published by the IEEE Computer Society (IEEE CS), represents the current state of generally accepted, consensus-based knowledge emanating from the interplay between software engineering theory and practice. Its objectives include the provision of guidance for learners, researchers, and practitioners to identify and share a common understanding of “generally accepted knowledge” in software engineering, defining the boundary between software engineering and related disciplines, and providing a foundation for certifications and educational curricula.
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 just to start a discussion and to be able to disagree on definitions and practices.
SWEBOK 4 adds a dedicated section for security, but it's painfully 2012 (testing, for instance, centers on the old industry-driven "SAST" vs. "DAST" distinction). It also promotes stuff like Common Criteria and CVSS. The "domain-specific" security section could have been pulled out of the OWASP wiki from 2012 as well: "cloud", "IOT", "machine learning".
Are there any freely available books you would recommend for 2024 security in software engineering?
(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.)
A core of the matter here is that good software development is heavily involved with _wisdom_, and in some sense, wisdom can not be stated badly, but must be oblique.
This book actually makes some sense to me as a software engineer. We’ve all learned this at school, but they were just scattered pieces of knowledge. This book actually offers a way of systematic organization of useful knowledge in production. Content is actually not for learning, but for quick check and review. The organization might not be perfect, but really is a way of reflecting on our understanding in this field.
So at the start of each chapter, the book has a table of abbreviations and their definitions, called 'Acronyms'. To whoever wrote or edited the book: please lookup the definition of the word 'acronym': "an abbreviation formed from the initial letters of other words and pronounced as a word (e.g. NASA)." Not all of the abbreviations listed are acronyms! Most are just plain old initialisms.
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?
There's literally an acronym for that type of acronym that itself is not an acronym: TLA. Three-letter acronym. I get the GP's frustration. When a word that you know the definition of is lost it feels bad.
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.
It's so unfortunate that this effort is still alive. The ACM canceled its involvement for excellent reasons which are worth reading: https://news.ycombinator.com/item?id=41593788, though there are many other examples). What is going on at IEEE?
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 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.
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 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.
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 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?
Formal methods have advanced enough now that any competent software engineer should know that it is at least an option. It's obviously not practical or necessary to apply everywhere but in any sufficiently large piece of software there are likely a few modules where applying formal methods would allow for faster, higher quality delivery at lower cost. Making those trade-offs and selecting appropriate approaches is the fundamental essence of engineering as a profession.
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.
> The ACM canceled its involvement for excellent reasons which are worth reading
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 ;-)
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 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 …
Although any random bathroom-wall graffiti is better than the SWEBOK, I don't know what to recommend that's actually good. Part of the problem is that people still suck at programming.
Not having read it, I hear The Pragmatic Programmer is pretty good. Code Complete was pretty great at the time. The Practice of Programming covers most of the same material but is much more compact and higher in quality; The C Programming Language, by one of the same authors, also teaches significant things. The Architecture of Open-Source Applications series isn't a handbook, but offers some pretty good ideas: https://aosabook.org/en/
Here are some key topics such a handbook or compendium ought to cover:
- How to think logically. This is crucial not only for debugging but also for formulating problems in such a way that you can program them into a computer. Programming problems that are small enough to fit into a programming interview can usually be solved, though badly, simply by rephrasing them in predicate logic (with some math, but usually not much) and mechanically transforming it into structured control flow. Real-world programming problems usually can't, but do have numerous such subproblems. I don't know how to teach this, but that's just my own incompetence at teaching.
- Debugging. You'll spend a lot of your time debugging, and there's more to debugging than just thinking logically. You also need to formulate good hypotheses (out of the whole set of logically possible ones) and run controlled experiments to validate them. There's a whole panoply of techniques available here, including testing, logging, input record and replay, delta debugging, stack trace analysis, breakpoint debuggers, metrics anomaly detection, and membrane interposition with things like strace.
- Testing. Though I mentioned this as a debugging technique, testing has a lot more applications than just debugging. Automated tests are crucial for finding and diagnosing bugs, and can also be used for design, performance profiling, and interface documentation. Manual tests are also crucial for finding and diagnosing bugs, and can also tell you about usability and reliability. There are a lot of techniques to learn here too, including unit testing, fuzzing, property-based testing, various kinds of test doubles (including mock objects), etc.
- Version tracking. Git is a huge improvement over CVS, but CVS is a huge improvement over Jupyter notebooks. Version control facilitates delta debugging, of course, but also protects against accidental typo insertion, overwriting new code with old code, losing your source code without backups, not being able to tell what your coworkers did, etc. And GitLab, Gitea, GitHub, etc., are useful in lots of ways.
- Reproducibility more generally. Debugging irreproducible problems is much more difficult, and source-code version tracking is only the start. It's very helpful to be able to reproduce your deployment environment(s), whether with Docker or with something else. When you can reproduce computational results, you can cache them safely, which is important for optimization.
- Stack Overflow. It's pretty common that you can find solutions to your problems easily on Stack Overflow and similar fora; twin pitfalls are blindly copying and pasting code from it without understanding it, and failing to take advantage of it even when it would greatly accelerate your progress.
- ChatGPT. We're still figuring out how to use large language models. Some promising approaches seem to be asking ChatGPT what some code does, how to use an unfamiliar API to accomplish some task that requires several calls, or how to implement an unfamiliar algorithm; and using ChatGPT as a simulated user for user testing. This has twin pitfalls similar to Stack Overflow. Asking it to write production-quality code for you tends to waste more time debugging its many carefully concealed bugs than it would take you to just write the code, but sometimes it may come up with a fresh approach you wouldn't have thought of.
- Using documentation in general. It's common for novice programmers to use poor-quality sites like w3schools instead of authoritative sites like python.org or MDN, and to be unfamiliar with the text of the standards they're nominally programming to. It's as if they think that any website that ranks well on Google is trustworthy! I've often found it very helpful to be able to look up the official definitions of things, and often official documentation has better ways to do things than outdated third-party answers. Writing documentation is actually a key part of this skill.
- Databases. There are a lot of times when storing your data in a transactional SQL database will save you an enormous amount of development effort, for several reasons: normalization makes invalid states unrepresentable; SQL, though verbose, can commonly express things in a fairly readable line or two that would take a page or more of nested loops, and many ORMs are about as good as SQL for many queries; transactions greatly simplify concurrency; and often it's easier to horizontally scale a SQL database than simpler alternatives. Not every application benefits from SQL, but applications that suffer from not using it are commonplace. Lacking data normalization, they suffer many easily avoidable bugs, and using procedural code where they could use SQL, they suffer not only more bugs but also difficulty in understanding and modification.
- Algorithms and data structures. SQL doesn't solve all your data storage and querying problems. As Zachary Vance said, "Usually you should do everything the simplest possible way, and if that fails, by brute force." But sometimes that doesn't work either. Writing a ray tracer, a Sudoku solver, a maze generator, or an NPC pathfinding algorithm doesn't get especially easier when you add SQL to the equation, and brute force will get you only so far. The study of algorithms can convert impossible programming problems into easy programming problems, and I think it may also be helpful for learning to think logically. The pitfall here is that it's easy to confuse the study of existing data structures and algorithms with software engineering as a whole.
- Design. It's always easy to add functionality to a small program, but hard to add functionality to a large program. But the order of growth of this difficulty depends on something we call "design". Well-designed large software can't be as easy to add functionality to as small software, but it can be much, much easier than poorly-designed large software. This, more than manpower or anything else, is what ultimately limits the functionality of software. It has more to do with how the pieces of the software are connected together than with how each one of them is written. Ultimately it has a profound impact on how each one of them is written. This is kind of a self-similar or fractal concern, applying at every level of composition that's bigger than a statement, and it's easy to have good high-level design and bad low-level design or vice versa. The best design is simple, but simplicity is not sufficient. Hierarchical decomposition is a central feature of good designs, but a hierarchical design is not necessarily a good design.
- Optimization. Sometimes the simplest possible way is too slow, and faster software is always better. So sometimes it's worthwhile to spend effort making software faster, though never actually optimal. Picking a better algorithm is generally the highest-impact thing you can do here when you can, but once you've done that, there are still a lot of other things you can do to make your software faster, at many different levels of composition.
- Code reviews. Two people can build software much more than twice as fast as one person. One of the reasons is that many bugs that are subtle to their author and hard to find by testing are obvious to someone else. Another is that often they can improve each other's designs.
- Regular expressions. Leaving aside the merits of understanding the automata-theory background, like SQL, regular expressions are in the category of things that can reduce a complicated page of code to a simple line of code, even if the most common syntax isn't very readable.
- Compilers, interpreters, and domain-specific languages. Regular expressions are a domain-specific language, and it's very common to have a problem domain that could be similarly simplified if you had a good domain-specific language for it, but you don't. Writing a compiler or interpreter for such a domain-specific language is one of the most powerful techniques for improving your system's design. Often you can use a so-called "embedded domain-specific language" that's really just a library for whatever language you're already using; this has advantages and disadvantages.
- Free-software licensing. If it works, using code somebody else wrote is very, very often faster than writing the code yourself. Unfortunately we have to concern ourselves with copyright law here; free-software licensing is what makes it legal to use other people's code most of the time, but you need to understand what the common licenses permit and how they can and cannot be combined.
- Specific software recommendations. There are certain pieces of software that are so commonly useful that you should just know about them, though this information has a shorter shelf life and is somewhat more domain-specific than the stuff above. But the handbook should list the currently popular libraries and analogous tools applicable to building software.
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 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.
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 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.
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.
I really don't think he means "cannot" in the sense of "presently don't know how," but more categorically--along the lines of chiropractic being the profession for those who cannot cure the way an MD can. I think it's an indictment of hackery.
Yes, there’s been a lot of negativity toward earlier versions of this document. It’s been around for a while and represents a formal, structured, and rigid approach to software development. Historically, it reflects the 1990s era, when waterfall was the preferred method, and there was a push to make software engineering a licensed profession. At the time, we were also in a “software crisis” where large, expensive projects with extensive documentation and formalized planning often failed. Today, we have quicker releases, faster feedback, and more direct user communication (what we now call extreme programming or agile). However, this has also led to too much cowboy programming. So it’s important to maintain some level of standards. Might be worth revisiting?
There was literally nothing in the SWEBOK which dictated a particular approach to software development, formal or otherwise. It has always been just a high-level list of knowledge areas and common definitions.
Well also now entire companies fail quicker instead.
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.
Taking a look at the index, a couple of issues which would make it not in my interest:
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.
I've noticed that a lot of engineering books cover concepts which are useful in the hands of senior developers but are harmful in the hands of junior developers because they misunderstand the nuance due to lack of experience.
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.
I would love to hear someone that actually works in a place that requires credentials like the PE comment on having a course based on this as a credential.
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.
I'm assuming you mean a single course? If so, this material would not be a standalone course. It would be baked into the entire bachelor's degree program. Some of the topics would maybe be more advanced or something that need to be demonstrated by being an EIT or writing the appropriate exams. For example, chapter 15 on engineering economics is a single class, but chapter 17 on mathematical foundations would cover at least 4 classes (discrete math, differential calculus, integral calculus, probability).
The US of A did have a software engineering principles and practices of engineering (PE) exam, but it's been discontinued, and I haven't managed to find an archived snapshot of the exam spec. I'm not American, but I think there is a common fundamentals of engineering (FE) exam [1] that has to be written to register as an EIT and then the PE [2] has to be written to be licensed and given the PE.
I'm not familiar with which American schools were ABET accredited in software engineering, but in Canada, several schools do have accredited software engineering majors. You can review the curriculum and see a fair amount of alignment to the SWEBOK topics. Again, some of these chapters could be split across multiple courses, but some chapters look more like a couple of weeks in one class.
For comparison, there is a 61 page industrial and systems engineering body of knowledge [3] available from the IISE (Institute of Industrial and Systems Engineers), which is really just a couple short paragraphs on each topic, a list of key areas within each, and a list of reference books. At a quick glance, all of the areas correspond to sections in the industrial FE [4] and the industrial PE [5].
> 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.
I'm not an engineer. I did an associates in engineering technology in Canada, so I'm a "pretengineer" at best. As far as I know, engineers in Canada have a discipline and then areas of practice. For industrial, there are 9 different areas of practice, but people are generally licensed to practice in 1 to 3.
In my region, software is not even broken out into its own areas of practice. Software is an area within computer engineering. I think software is way too vast right now and the expectations are much too big. So, the traditional engineers have much more limited scope problems. But I could be limited by my perspective and lack of license.
In the US most engineers do not have the PE and many (might be most, but I couldn't find the numbers) do not take the FE exam.
In the States most people working on software have computer science degrees, not software engineering degrees.
In general there is not a huge amount of certification overhead for engineers in the US, despite what some people seem to think, and I'm quite happy that's the way it is.
I was mostly looking for perspectives on how requiring credentials like these impacted actual work and workplaces.
The parable of the blind men and an elephant is a story of a group of blind
men who have never come across an elephant before and who learn and imagine
what the elephant is like by touching it. Each blind man feels a different
part of the animal's body, but only one part, such as the side or the tusk.
They then describe the animal based on their limited experience and their
descriptions of the elephant are different from each other. In some
versions, they come to suspect that the other person is dishonest and they
come to blows. The moral of the parable is that humans have a tendency to
claim absolute truth based on their limited, subjective experience as they
ignore other people's limited, subjective experiences which may be equally
true.[1][2] The parable originated in the ancient Indian subcontinent, from
where it has been widely diffused.
So section 2 does not jibe with enterprise development, section 3 does not agree with embedded development, and section 8 does not fit well with web startups?
These three industries have different requirements, not just from each other but from controllers for skyscrapers and space probes too.
This document is trying to find common ground, and so will offend folks in camp X, Y, or Z that their case is not handled well enough. Please be mindful that other sets of requirements exist.
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.
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.
That line is referring to shared libraries linked to a dynamic executable. If a shared library isn't installed or available you will receive an error similar to the following:
$ ./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.
What exactly is wrong with it? That is a definition fit for someone who does not have prior knowledge of what a runtime error is. It might be boring to us, and I might word it a little different, but it's fine.
For me it's the last sentence: "Once identified, runtime errors are easy to fix." Well no not really - it depends on the issue; sometimes a solution isn't 'fixing' it, sometimes choosing what to do next after identifying the root cause is it's own task. Maybe it's working around it, like amending the return value with amended data, or patching the API itself by wrapping it in an intermediate API and swallowing exceptions. Guidance on addressing runtime errors should never presuppose that 'fixing' it will be easy - it will always depend on the context. Just get rid of that last sentence and it's a better statement.
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.
> Runtime errors surface when a program runs into an unexpected condition or situation such as dividing by zero,
This implicitly asserts that dividing by zero is always unexpected, that all runtime errors are unexpected, and that dividing by zero always causes a runtime error. None of these are true. Dividing by zero is very frequently not unexpected (it's utterly commonplace in 3-D graphics, for example, when a vertex happens to be in the camera's focal plane) and in floating-point math (standardized by, ironically, the IEEE) it doesn't generate runtime errors by default. Moreover, there are certain applications where runtime errors are also expected, such as in fuzzers. Some languages frequently use their runtime error mechanism to convey perfectly mundane conditions such as not finding a key in a hash table or coming to the end of a sequence. And it's fairly often a useful mechanism for terminating a recursive search procedure.
> memory overflow,
There's no such thing as a "memory overflow" on any platform I'm familiar with. This might have been intended to reference any of five things: stack overflows, buffer overflows, heap allocation failures, resource limit exhaustion, or OOM kills.
The stack is an area of memory, and a "stack overflow" is an attempt to put too much data in it, usually due to an infinite recursive loop. Stack overflows do often get detected as runtime errors, but many platforms fail to detect them, causing incorrect program behavior instead.
A buffer is also an area of memory (an array) and a "buffer overflow" is an attempt to put too much data in it, usually due to an omitted check on input data size. Buffer overflows do sometimes get detected as runtime errors, but often do not, because the most popular implementations of many popular programming languages (notably C, C++, and Pascal) do not do automatic bounds checking.
Heap allocation failures are attempts to dynamically allocate memory that are denied, often because too much memory is already allocated, so in a sense your heap memory has "overflowed". Some programming languages handle this as a runtime error, but the most popular implementations of many popular programming languages (notably C, C++, and Pascal) do not.
Resource limit exhaustion is a condition where a program exceeds operating-system-imposed limits on its usage of resources such as CPU time, output file size, or memory usage, in response to which the OS raises a runtime error. On Unix this manifests as killing the process with a signal.
OOM kills are a Linux thing where the OS starts killing resource-intensive processes to attempt to recover from a memory overload condition that is degrading service badly. In a sense the computer's memory has "overflowed", so Unix's runtime error mechanism is pressed into service. (Something very similar happens if you press ^C, though, so describing this as a "runtime error" is maybe not defensible.)
> or addressing a wrong or unauthorized memory location or device,
The standard verb here would be "accessing", not "addressing", but I don't want to make too much of the use of nonstandard terminology; it's not always an indicator of unfamiliarity with the field. And there are indeed machines where there are kinds of "wrong" other than "unauthorized"—that's why we have SIGBUS, for unaligned access exceptions on CPUs that don't support unaligned access.
But "device" is, as far as I know, wrong; I don't know of any platform which raises a runtime error when you try to access the wrong device. There are a number of platforms that have I/O instructions which will raise a runtime error if you try to use them in unprivileged code, but that doesn't depend on which device you're accessing. Usually in small microcontrollers there isn't any kind of runtime-error mechanism, and when there is, it generally isn't invoked for I/O instructions. Sometimes you can set up the MPU so that certain code can't access devices—when they're memory-mapped, in which case "memory location" would have covered the case.
Even if there is some platform where it's possible to get a runtime error accessing the wrong device, it's far from the kind of common case you'd want to include in such an abbreviated list of typical causes of runtime errors "for someone who does not have prior knowledge of what a runtime error is". Much more typical would be illegal instructions, attempts to access privileged state from unprivileged code, null pointer dereferences, runtime type errors such as ClassCastException, and array bounds violations, none of which are mentioned.
It seems like someone who doesn't know anything about software was trying to imagine what kinds of things might, in theory, cause runtime errors, but the kinds of protection mechanisms they imagined were completely different from the ones used in actual existing computers.
> or when a program tries to perform an illegitimate or unauthorized operation
As a simple matter of logic, this subsumes the previous item, and "illegitimate" in this context means the same thing as "unauthorized". So this list is not just comprehensively wrong at a technical level, but also so badly written as to be incoherent.
> or tries to access a library, for example.
This is completely wrong. Of course a program can get a runtime error when it tries to load a library, just as it can get a runtime error when it undertakes any other task, but there is no platform that raises a runtime error whenever you try to access a library.
> 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.
This statement, in itself, only contains a couple of slight factual errors.
First, it says that the inputs to programs are data sets. This is probably something that someone who doesn't know anything about software copied from a 60-year-old textbook, because at that time, the inputs to programs were data sets (now more commonly known as files). In fact, the more important inputs to programs nowadays are things such as user interactions, data received over a network, and data received in real time from sensors such as microphones, oxygen sensors, and accelerometers. But this statement is stuck in punched-card land, where programs punched into card decks ran in batch mode to process some input data sets and produce some output data sets.
The second factual error is that it implies that runtime errors result primarily from inputs and how the program responds to them. And, of course, there are runtime errors that are determined by the program's handling of inputs; typically type errors, null pointer exceptions, array bounds violations, etc., can be reproduced if you run the program again with the same input. But large classes of runtime errors do not fit this profile. Some are errors that depend on internal nondeterminism in the program, such as nondeterministic interactions between different threads (we would say "scheduler interleaving order" back in the single-core days), or nondeterministic timing. Others depend on runtime conditions like how much memory is available to allocate or how full the disk is (writing to a full disk in Python raises an exception, though not in many other languages). Others result from hardware problems such as overheating. The statement does, in passing, say "and conditions", but these are given short shrift.
The much bigger problem with this statement, though, is that it's in the middle of a paragraph about runtime errors. But everything it says is equally applicable to logic errors, the subject of the next paragraph; indeed, much of it is more applicable to logic errors. Putting it in the middle of this paragraph misleadingly implies that things like testing with invalid input files (or the other, more important, invalid inputs it failed to mention) are uniquely or primarily applicable to runtime errors.
> Once identified, runtime errors are easy to fix.
This statement is also wrong in a multidimensional way.
First, although this is in the "debugging" section, many runtime errors aren't bugs at all. A program crashing with a MemoryError or OutOfMemoryError when it is run with insufficient memory available to allocate is, in general, desired behavior. It's also often the desired behavior when it's applied to a too-large input, though obviously that's not acceptable for games or avionics software. The same is true of permission errors, out-of-disk-space errors, etc. These are specifically the kind of runtime errors that most commonly result from the "and conditions" in the previous sentence.
Second, while it's usually easier to debug a segfault or exception than silently incorrect output, it is often far from trivial to track down the runtime error to its ultimate cause.
Third, even when you have figured out what the ultimate cause is, fixing it is sometimes not easy, for example because other people's deployed software depends on interfaces you have to change, or more generally because it is difficult to understand what other problems could be caused by the possible fixes you are considering.
By my count, that's 12 significant factual errors in 86 words, an average of 7.2 words per error. This is an error density that would be impressive in any contexts, although I've occasionally seen expert liars exceed it somewhat. In the context of an official publication purporting to establish standards for professional competence, it's utterly horrifying.
So this is not a definition fit for anyone, least of all someone who does not have prior knowledge of what a runtime error is; it is very far from being fine. It's embarrassing horseshit.
And it's not just this one paragraph. Virtually the entire document is like this. Occasionally you'll find a paragraph that's mostly correct from beginning to end, but then it'll be followed by the cringiest idiocy you can possibly imagine in the very next paragraph.
With respect to this paragraph in particular, an even worse problem than its unreliability is emphasis. This is from §4.6, "Debugging", which is 189 words, about a quarter of p. 16-13 (p. 326/413). Debugging is arguably the central activity of software engineering; about a quarter of the effort† spent on software engineering is spent on debugging, an amount which would be larger if we didn't spend so much effort on avoiding debugging (for example, with type systems, unit tests, version control, and documentation). Any actual software engineering body of knowledge would be largely concerned with knowledge about debugging. But the IEEE relegates it to 0.2% of their document.
I suppose, yeah, when I figure out the exact reason why the error occurred, fixing it is often easy. The finding, however, can often take a long time, which leaves me feeling "once you have driven across the continent, finding your desired endpoint is a quick process". "Once constructed, installing the door on your new house is a simple and easy task". Well, sure, if you take out the time-consuming parts, it's quick and easy.
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.
This is the embarrassing bit; this is version 4 of a book that predates ChatGPT by years; knowing that probably most of it is written by humans makes me cringe.
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)
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.
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.
5 replies →
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.
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.
3 replies →
SE is not CS of course. Very few of us will write compilers, for example.
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.
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).
> 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.
Maybe that’s not a bad thing…
18 replies →
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.
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.
6 replies →
> 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?
>> 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.
7 replies →
> 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://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.
Swebok is an attempt to look at the whole ox
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'm convinced slowing feeding students, and having them produce good low-level codebase(s) (e.g. OSs, compilers) is a great Way to "holistically" teach them CS, much better than what's happening usually. "C is a razor-sharp tool"!
Even he admits, he had to start somewhere.
The Master might say something like this, if translated crudely -
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.
5 replies →
> The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), published by the IEEE Computer Society (IEEE CS), represents the current state of generally accepted, consensus-based knowledge emanating from the interplay between software engineering theory and practice. Its objectives include the provision of guidance for learners, researchers, and practitioners to identify and share a common understanding of “generally accepted knowledge” in software engineering, defining the boundary between software engineering and related disciplines, and providing a foundation for certifications and educational curricula.
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 just to start a discussion and to be able to disagree on definitions and practices.
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.
SWEBOK 4 adds a dedicated section for security, but it's painfully 2012 (testing, for instance, centers on the old industry-driven "SAST" vs. "DAST" distinction). It also promotes stuff like Common Criteria and CVSS. The "domain-specific" security section could have been pulled out of the OWASP wiki from 2012 as well: "cloud", "IOT", "machine learning".
Are there any freely available books you would recommend for 2024 security in software engineering?
(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.)
Believe it is supposed to be slow-moving, keeping to settled matters. Have those fallen out of favor, or shown to be wrong already?
I would not describe SWEBOK's breakdown of software security as "settled".
Apparently I am also stuck in 2012 - are we not doing cloud and machine learning anymore?
A competing and altogether more entertaining and comprehensive body of knowledge: https://grugbrain.dev/
This is a good resource.
A core of the matter here is that good software development is heavily involved with _wisdom_, and in some sense, wisdom can not be stated badly, but must be oblique.
Add to that https://github.com/Droogans/unmaintainable-code
This book actually makes some sense to me as a software engineer. We’ve all learned this at school, but they were just scattered pieces of knowledge. This book actually offers a way of systematic organization of useful knowledge in production. Content is actually not for learning, but for quick check and review. The organization might not be perfect, but really is a way of reflecting on our understanding in this field.
Did we all? I haven't done a lot of this during my master's and neither did any of my friends (that's across multiple countries/unis).
But yeah, it's a really interesting way to organise the knowledge.
What did you do?
1 reply →
> Popular OOP languages include C++, C#, Cobol 2002, Java, Python, Lisp, Perl, Object Pascal, Ruby and Smalltalk.
:)
So at the start of each chapter, the book has a table of abbreviations and their definitions, called 'Acronyms'. To whoever wrote or edited the book: please lookup the definition of the word 'acronym': "an abbreviation formed from the initial letters of other words and pronounced as a word (e.g. NASA)." Not all of the abbreviations listed are acronyms! Most are just plain old initialisms.
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?
From Merriam Webster:
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.
There's literally an acronym for that type of acronym that itself is not an acronym: TLA. Three-letter acronym. I get the GP's frustration. When a word that you know the definition of is lost it feels bad.
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.
1 reply →
yeah, every time i see somebody call an initialism an acronym i just shrug because you can't argue with words how people use them, irregardless.
It's so unfortunate that this effort is still alive. The ACM canceled its involvement for excellent reasons which are worth reading: https://news.ycombinator.com/item?id=41593788, though there are many other examples). What is going on at IEEE?
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 then details exactly how SWEBOK fails to meet those (which all still seem to be relevant) and comes to the following scathing conclusion:
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.
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 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.
5 replies →
On a tangent here, but...
> 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?
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 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?
Formal methods have advanced enough now that any competent software engineer should know that it is at least an option. It's obviously not practical or necessary to apply everywhere but in any sufficiently large piece of software there are likely a few modules where applying formal methods would allow for faster, higher quality delivery at lower cost. Making those trade-offs and selecting appropriate approaches is the fundamental essence of engineering as a profession.
1 reply →
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.
Since we’re talking Dijkstra, perhaps “structured programming” is a starting place.
> The ACM canceled its involvement for excellent reasons which are worth reading
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 ;-)
Any suggestion for a handbook or compendium that you consider to be a worthy alternative?
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 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.
5 replies →
Although any random bathroom-wall graffiti is better than the SWEBOK, I don't know what to recommend that's actually good. Part of the problem is that people still suck at programming.
“How to report bugs effectively” <https://www.chiark.greenend.org.uk/~sgtatham/bugs.html> is probably the highest-bang-for-buck reading on software engineering.
Not having read it, I hear The Pragmatic Programmer is pretty good. Code Complete was pretty great at the time. The Practice of Programming covers most of the same material but is much more compact and higher in quality; The C Programming Language, by one of the same authors, also teaches significant things. The Architecture of Open-Source Applications series isn't a handbook, but offers some pretty good ideas: https://aosabook.org/en/
Here are some key topics such a handbook or compendium ought to cover:
- How to think logically. This is crucial not only for debugging but also for formulating problems in such a way that you can program them into a computer. Programming problems that are small enough to fit into a programming interview can usually be solved, though badly, simply by rephrasing them in predicate logic (with some math, but usually not much) and mechanically transforming it into structured control flow. Real-world programming problems usually can't, but do have numerous such subproblems. I don't know how to teach this, but that's just my own incompetence at teaching.
- Debugging. You'll spend a lot of your time debugging, and there's more to debugging than just thinking logically. You also need to formulate good hypotheses (out of the whole set of logically possible ones) and run controlled experiments to validate them. There's a whole panoply of techniques available here, including testing, logging, input record and replay, delta debugging, stack trace analysis, breakpoint debuggers, metrics anomaly detection, and membrane interposition with things like strace.
- Testing. Though I mentioned this as a debugging technique, testing has a lot more applications than just debugging. Automated tests are crucial for finding and diagnosing bugs, and can also be used for design, performance profiling, and interface documentation. Manual tests are also crucial for finding and diagnosing bugs, and can also tell you about usability and reliability. There are a lot of techniques to learn here too, including unit testing, fuzzing, property-based testing, various kinds of test doubles (including mock objects), etc.
- Version tracking. Git is a huge improvement over CVS, but CVS is a huge improvement over Jupyter notebooks. Version control facilitates delta debugging, of course, but also protects against accidental typo insertion, overwriting new code with old code, losing your source code without backups, not being able to tell what your coworkers did, etc. And GitLab, Gitea, GitHub, etc., are useful in lots of ways.
- Reproducibility more generally. Debugging irreproducible problems is much more difficult, and source-code version tracking is only the start. It's very helpful to be able to reproduce your deployment environment(s), whether with Docker or with something else. When you can reproduce computational results, you can cache them safely, which is important for optimization.
- Stack Overflow. It's pretty common that you can find solutions to your problems easily on Stack Overflow and similar fora; twin pitfalls are blindly copying and pasting code from it without understanding it, and failing to take advantage of it even when it would greatly accelerate your progress.
- ChatGPT. We're still figuring out how to use large language models. Some promising approaches seem to be asking ChatGPT what some code does, how to use an unfamiliar API to accomplish some task that requires several calls, or how to implement an unfamiliar algorithm; and using ChatGPT as a simulated user for user testing. This has twin pitfalls similar to Stack Overflow. Asking it to write production-quality code for you tends to waste more time debugging its many carefully concealed bugs than it would take you to just write the code, but sometimes it may come up with a fresh approach you wouldn't have thought of.
- Using documentation in general. It's common for novice programmers to use poor-quality sites like w3schools instead of authoritative sites like python.org or MDN, and to be unfamiliar with the text of the standards they're nominally programming to. It's as if they think that any website that ranks well on Google is trustworthy! I've often found it very helpful to be able to look up the official definitions of things, and often official documentation has better ways to do things than outdated third-party answers. Writing documentation is actually a key part of this skill.
- Databases. There are a lot of times when storing your data in a transactional SQL database will save you an enormous amount of development effort, for several reasons: normalization makes invalid states unrepresentable; SQL, though verbose, can commonly express things in a fairly readable line or two that would take a page or more of nested loops, and many ORMs are about as good as SQL for many queries; transactions greatly simplify concurrency; and often it's easier to horizontally scale a SQL database than simpler alternatives. Not every application benefits from SQL, but applications that suffer from not using it are commonplace. Lacking data normalization, they suffer many easily avoidable bugs, and using procedural code where they could use SQL, they suffer not only more bugs but also difficulty in understanding and modification.
- Algorithms and data structures. SQL doesn't solve all your data storage and querying problems. As Zachary Vance said, "Usually you should do everything the simplest possible way, and if that fails, by brute force." But sometimes that doesn't work either. Writing a ray tracer, a Sudoku solver, a maze generator, or an NPC pathfinding algorithm doesn't get especially easier when you add SQL to the equation, and brute force will get you only so far. The study of algorithms can convert impossible programming problems into easy programming problems, and I think it may also be helpful for learning to think logically. The pitfall here is that it's easy to confuse the study of existing data structures and algorithms with software engineering as a whole.
- Design. It's always easy to add functionality to a small program, but hard to add functionality to a large program. But the order of growth of this difficulty depends on something we call "design". Well-designed large software can't be as easy to add functionality to as small software, but it can be much, much easier than poorly-designed large software. This, more than manpower or anything else, is what ultimately limits the functionality of software. It has more to do with how the pieces of the software are connected together than with how each one of them is written. Ultimately it has a profound impact on how each one of them is written. This is kind of a self-similar or fractal concern, applying at every level of composition that's bigger than a statement, and it's easy to have good high-level design and bad low-level design or vice versa. The best design is simple, but simplicity is not sufficient. Hierarchical decomposition is a central feature of good designs, but a hierarchical design is not necessarily a good design.
- Optimization. Sometimes the simplest possible way is too slow, and faster software is always better. So sometimes it's worthwhile to spend effort making software faster, though never actually optimal. Picking a better algorithm is generally the highest-impact thing you can do here when you can, but once you've done that, there are still a lot of other things you can do to make your software faster, at many different levels of composition.
- Code reviews. Two people can build software much more than twice as fast as one person. One of the reasons is that many bugs that are subtle to their author and hard to find by testing are obvious to someone else. Another is that often they can improve each other's designs.
- Regular expressions. Leaving aside the merits of understanding the automata-theory background, like SQL, regular expressions are in the category of things that can reduce a complicated page of code to a simple line of code, even if the most common syntax isn't very readable.
- Compilers, interpreters, and domain-specific languages. Regular expressions are a domain-specific language, and it's very common to have a problem domain that could be similarly simplified if you had a good domain-specific language for it, but you don't. Writing a compiler or interpreter for such a domain-specific language is one of the most powerful techniques for improving your system's design. Often you can use a so-called "embedded domain-specific language" that's really just a library for whatever language you're already using; this has advantages and disadvantages.
- Free-software licensing. If it works, using code somebody else wrote is very, very often faster than writing the code yourself. Unfortunately we have to concern ourselves with copyright law here; free-software licensing is what makes it legal to use other people's code most of the time, but you need to understand what the common licenses permit and how they can and cannot be combined.
- Specific software recommendations. There are certain pieces of software that are so commonly useful that you should just know about them, though this information has a shorter shelf life and is somewhat more domain-specific than the stuff above. But the handbook should list the currently popular libraries and analogous tools applicable to building software.
2 replies →
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 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.
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 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.
3 replies →
>What is going on at IEEE?
The IEEE has been a worn-out, irrelevant relic of the past for at least 2 decades now.
> 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.
I really don't think he means "cannot" in the sense of "presently don't know how," but more categorically--along the lines of chiropractic being the profession for those who cannot cure the way an MD can. I think it's an indictment of hackery.
Yes, there’s been a lot of negativity toward earlier versions of this document. It’s been around for a while and represents a formal, structured, and rigid approach to software development. Historically, it reflects the 1990s era, when waterfall was the preferred method, and there was a push to make software engineering a licensed profession. At the time, we were also in a “software crisis” where large, expensive projects with extensive documentation and formalized planning often failed. Today, we have quicker releases, faster feedback, and more direct user communication (what we now call extreme programming or agile). However, this has also led to too much cowboy programming. So it’s important to maintain some level of standards. Might be worth revisiting?
There was literally nothing in the SWEBOK which dictated a particular approach to software development, formal or otherwise. It has always been just a high-level list of knowledge areas and common definitions.
Well also now entire companies fail quicker instead.
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.
For me "BOK" is correlated with the creation of false industry and certification.
Taking a look at the index, a couple of issues which would make it not in my interest:
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.
I've noticed that a lot of engineering books cover concepts which are useful in the hands of senior developers but are harmful in the hands of junior developers because they misunderstand the nuance due to lack of experience.
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.
I would love to hear someone that actually works in a place that requires credentials like the PE comment on having a course based on this as a credential.
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.
> having a course based on this as a credential.
I'm assuming you mean a single course? If so, this material would not be a standalone course. It would be baked into the entire bachelor's degree program. Some of the topics would maybe be more advanced or something that need to be demonstrated by being an EIT or writing the appropriate exams. For example, chapter 15 on engineering economics is a single class, but chapter 17 on mathematical foundations would cover at least 4 classes (discrete math, differential calculus, integral calculus, probability).
The US of A did have a software engineering principles and practices of engineering (PE) exam, but it's been discontinued, and I haven't managed to find an archived snapshot of the exam spec. I'm not American, but I think there is a common fundamentals of engineering (FE) exam [1] that has to be written to register as an EIT and then the PE [2] has to be written to be licensed and given the PE.
I'm not familiar with which American schools were ABET accredited in software engineering, but in Canada, several schools do have accredited software engineering majors. You can review the curriculum and see a fair amount of alignment to the SWEBOK topics. Again, some of these chapters could be split across multiple courses, but some chapters look more like a couple of weeks in one class.
For comparison, there is a 61 page industrial and systems engineering body of knowledge [3] available from the IISE (Institute of Industrial and Systems Engineers), which is really just a couple short paragraphs on each topic, a list of key areas within each, and a list of reference books. At a quick glance, all of the areas correspond to sections in the industrial FE [4] and the industrial PE [5].
> 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.
I'm not an engineer. I did an associates in engineering technology in Canada, so I'm a "pretengineer" at best. As far as I know, engineers in Canada have a discipline and then areas of practice. For industrial, there are 9 different areas of practice, but people are generally licensed to practice in 1 to 3.
In my region, software is not even broken out into its own areas of practice. Software is an area within computer engineering. I think software is way too vast right now and the expectations are much too big. So, the traditional engineers have much more limited scope problems. But I could be limited by my perspective and lack of license.
[1] https://ncees.org/exams/fe-exam/
[2] https://ncees.org/exams/pe-exam/
[3] https://www.iise.org/Details.aspx?id=43631
Links to PDFs
[4] https://ncees.org/wp-content/uploads/2022/09/FE-Industrial-a...
[5] https://ncees.org/wp-content/uploads/2024/10/PE-Ind-Oct-2020...
In the US most engineers do not have the PE and many (might be most, but I couldn't find the numbers) do not take the FE exam.
In the States most people working on software have computer science degrees, not software engineering degrees.
In general there is not a huge amount of certification overhead for engineers in the US, despite what some people seem to think, and I'm quite happy that's the way it is.
I was mostly looking for perspectives on how requiring credentials like these impacted actual work and workplaces.
300 pages* is perhaps not quite the length one would expect for Version 4.0 of such an ambitious undertaking.
* Actual page count less front/back matter and a rough guess at pages of matrices and references.
this is a book for people who think the wizard on the cover of SICP is an actual wizard and get scared
A lot of scathing critiques in here, but they remind me of the parable of the blind folks and the elephant. https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
So section 2 does not jibe with enterprise development, section 3 does not agree with embedded development, and section 8 does not fit well with web startups? These three industries have different requirements, not just from each other but from controllers for skyscrapers and space probes too.
This document is trying to find common ground, and so will offend folks in camp X, Y, or Z that their case is not handled well enough. Please be mindful that other sets of requirements exist.
If you really want someone interested in software development to run away, hand them books like this one.
This is meant for engineers, a certification-like body of the core knowledge of the field.
This was my first thought.
If this ever starts to get thought in CS university courses the amount of devs would dramaticaly reduce due to trauma.
Software quality may increase though, because there's a desperate lack of solid engineering practices across the industry.
this is a list of books mentioned
https://www.goodreads.com/list/show/121496.SWEBOK_Consolidat...
Embarrassing horseshit.
> or tries to access a library
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.
That line is referring to shared libraries linked to a dynamic executable. If a shared library isn't installed or available you will receive an error similar to the following:
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.
4 replies →
What exactly is wrong with it? That is a definition fit for someone who does not have prior knowledge of what a runtime error is. It might be boring to us, and I might word it a little different, but it's fine.
For me it's the last sentence: "Once identified, runtime errors are easy to fix." Well no not really - it depends on the issue; sometimes a solution isn't 'fixing' it, sometimes choosing what to do next after identifying the root cause is it's own task. Maybe it's working around it, like amending the return value with amended data, or patching the API itself by wrapping it in an intermediate API and swallowing exceptions. Guidance on addressing runtime errors should never presuppose that 'fixing' it will be easy - it will always depend on the context. Just get rid of that last sentence and it's a better statement.
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.
1 reply →
A lot of things are wrong with it.
> Runtime errors surface when a program runs into an unexpected condition or situation such as dividing by zero,
This implicitly asserts that dividing by zero is always unexpected, that all runtime errors are unexpected, and that dividing by zero always causes a runtime error. None of these are true. Dividing by zero is very frequently not unexpected (it's utterly commonplace in 3-D graphics, for example, when a vertex happens to be in the camera's focal plane) and in floating-point math (standardized by, ironically, the IEEE) it doesn't generate runtime errors by default. Moreover, there are certain applications where runtime errors are also expected, such as in fuzzers. Some languages frequently use their runtime error mechanism to convey perfectly mundane conditions such as not finding a key in a hash table or coming to the end of a sequence. And it's fairly often a useful mechanism for terminating a recursive search procedure.
> memory overflow,
There's no such thing as a "memory overflow" on any platform I'm familiar with. This might have been intended to reference any of five things: stack overflows, buffer overflows, heap allocation failures, resource limit exhaustion, or OOM kills.
The stack is an area of memory, and a "stack overflow" is an attempt to put too much data in it, usually due to an infinite recursive loop. Stack overflows do often get detected as runtime errors, but many platforms fail to detect them, causing incorrect program behavior instead.
A buffer is also an area of memory (an array) and a "buffer overflow" is an attempt to put too much data in it, usually due to an omitted check on input data size. Buffer overflows do sometimes get detected as runtime errors, but often do not, because the most popular implementations of many popular programming languages (notably C, C++, and Pascal) do not do automatic bounds checking.
Heap allocation failures are attempts to dynamically allocate memory that are denied, often because too much memory is already allocated, so in a sense your heap memory has "overflowed". Some programming languages handle this as a runtime error, but the most popular implementations of many popular programming languages (notably C, C++, and Pascal) do not.
Resource limit exhaustion is a condition where a program exceeds operating-system-imposed limits on its usage of resources such as CPU time, output file size, or memory usage, in response to which the OS raises a runtime error. On Unix this manifests as killing the process with a signal.
OOM kills are a Linux thing where the OS starts killing resource-intensive processes to attempt to recover from a memory overload condition that is degrading service badly. In a sense the computer's memory has "overflowed", so Unix's runtime error mechanism is pressed into service. (Something very similar happens if you press ^C, though, so describing this as a "runtime error" is maybe not defensible.)
> or addressing a wrong or unauthorized memory location or device,
The standard verb here would be "accessing", not "addressing", but I don't want to make too much of the use of nonstandard terminology; it's not always an indicator of unfamiliarity with the field. And there are indeed machines where there are kinds of "wrong" other than "unauthorized"—that's why we have SIGBUS, for unaligned access exceptions on CPUs that don't support unaligned access.
But "device" is, as far as I know, wrong; I don't know of any platform which raises a runtime error when you try to access the wrong device. There are a number of platforms that have I/O instructions which will raise a runtime error if you try to use them in unprivileged code, but that doesn't depend on which device you're accessing. Usually in small microcontrollers there isn't any kind of runtime-error mechanism, and when there is, it generally isn't invoked for I/O instructions. Sometimes you can set up the MPU so that certain code can't access devices—when they're memory-mapped, in which case "memory location" would have covered the case.
Even if there is some platform where it's possible to get a runtime error accessing the wrong device, it's far from the kind of common case you'd want to include in such an abbreviated list of typical causes of runtime errors "for someone who does not have prior knowledge of what a runtime error is". Much more typical would be illegal instructions, attempts to access privileged state from unprivileged code, null pointer dereferences, runtime type errors such as ClassCastException, and array bounds violations, none of which are mentioned.
It seems like someone who doesn't know anything about software was trying to imagine what kinds of things might, in theory, cause runtime errors, but the kinds of protection mechanisms they imagined were completely different from the ones used in actual existing computers.
> or when a program tries to perform an illegitimate or unauthorized operation
As a simple matter of logic, this subsumes the previous item, and "illegitimate" in this context means the same thing as "unauthorized". So this list is not just comprehensively wrong at a technical level, but also so badly written as to be incoherent.
> or tries to access a library, for example.
This is completely wrong. Of course a program can get a runtime error when it tries to load a library, just as it can get a runtime error when it undertakes any other task, but there is no platform that raises a runtime error whenever you try to access a library.
> 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.
This statement, in itself, only contains a couple of slight factual errors.
First, it says that the inputs to programs are data sets. This is probably something that someone who doesn't know anything about software copied from a 60-year-old textbook, because at that time, the inputs to programs were data sets (now more commonly known as files). In fact, the more important inputs to programs nowadays are things such as user interactions, data received over a network, and data received in real time from sensors such as microphones, oxygen sensors, and accelerometers. But this statement is stuck in punched-card land, where programs punched into card decks ran in batch mode to process some input data sets and produce some output data sets.
The second factual error is that it implies that runtime errors result primarily from inputs and how the program responds to them. And, of course, there are runtime errors that are determined by the program's handling of inputs; typically type errors, null pointer exceptions, array bounds violations, etc., can be reproduced if you run the program again with the same input. But large classes of runtime errors do not fit this profile. Some are errors that depend on internal nondeterminism in the program, such as nondeterministic interactions between different threads (we would say "scheduler interleaving order" back in the single-core days), or nondeterministic timing. Others depend on runtime conditions like how much memory is available to allocate or how full the disk is (writing to a full disk in Python raises an exception, though not in many other languages). Others result from hardware problems such as overheating. The statement does, in passing, say "and conditions", but these are given short shrift.
The much bigger problem with this statement, though, is that it's in the middle of a paragraph about runtime errors. But everything it says is equally applicable to logic errors, the subject of the next paragraph; indeed, much of it is more applicable to logic errors. Putting it in the middle of this paragraph misleadingly implies that things like testing with invalid input files (or the other, more important, invalid inputs it failed to mention) are uniquely or primarily applicable to runtime errors.
> Once identified, runtime errors are easy to fix.
This statement is also wrong in a multidimensional way.
First, although this is in the "debugging" section, many runtime errors aren't bugs at all. A program crashing with a MemoryError or OutOfMemoryError when it is run with insufficient memory available to allocate is, in general, desired behavior. It's also often the desired behavior when it's applied to a too-large input, though obviously that's not acceptable for games or avionics software. The same is true of permission errors, out-of-disk-space errors, etc. These are specifically the kind of runtime errors that most commonly result from the "and conditions" in the previous sentence.
Second, while it's usually easier to debug a segfault or exception than silently incorrect output, it is often far from trivial to track down the runtime error to its ultimate cause.
Third, even when you have figured out what the ultimate cause is, fixing it is sometimes not easy, for example because other people's deployed software depends on interfaces you have to change, or more generally because it is difficult to understand what other problems could be caused by the possible fixes you are considering.
By my count, that's 12 significant factual errors in 86 words, an average of 7.2 words per error. This is an error density that would be impressive in any contexts, although I've occasionally seen expert liars exceed it somewhat. In the context of an official publication purporting to establish standards for professional competence, it's utterly horrifying.
So this is not a definition fit for anyone, least of all someone who does not have prior knowledge of what a runtime error is; it is very far from being fine. It's embarrassing horseshit.
And it's not just this one paragraph. Virtually the entire document is like this. Occasionally you'll find a paragraph that's mostly correct from beginning to end, but then it'll be followed by the cringiest idiocy you can possibly imagine in the very next paragraph.
With respect to this paragraph in particular, an even worse problem than its unreliability is emphasis. This is from §4.6, "Debugging", which is 189 words, about a quarter of p. 16-13 (p. 326/413). Debugging is arguably the central activity of software engineering; about a quarter of the effort† spent on software engineering is spent on debugging, an amount which would be larger if we didn't spend so much effort on avoiding debugging (for example, with type systems, unit tests, version control, and documentation). Any actual software engineering body of knowledge would be largely concerned with knowledge about debugging. But the IEEE relegates it to 0.2% of their document.
______
† in https://www.quora.com/In-a-typical-software-engineering-comp... Raja Nagendra Kumar says 80% in IT services and typically 20–50% in "product companies", and Gene Sewell says ⅓ of the time; in https://www.quora.com/How-much-time-does-a-programmer-spend-... Ben Gamble says 5–70% of each day and Stephen Bear says ideally about 10% if you're doing everything else right; https://old.reddit.com/r/learnprogramming/comments/1eclw4l/i... complains about spending 60–70% of their time debugging; https://old.reddit.com/r/computerscience/comments/lwemi5/is_... quotes the Embedded Market Survey as saying 20%, while other people report numbers as high as 80%; https://craftbettersoftware.com/p/debugging-the-biggest-wast... says 50%, referencing https://www.researchgate.net/publication/345843594_Reversibl.... So I think "a quarter" is a pretty reasonable ballpark.
11 replies →
Software development is one of those things that's easy until you have to actually sit down and do it.
I suppose, yeah, when I figure out the exact reason why the error occurred, fixing it is often easy. The finding, however, can often take a long time, which leaves me feeling "once you have driven across the continent, finding your desired endpoint is a quick process". "Once constructed, installing the door on your new house is a simple and easy task". Well, sure, if you take out the time-consuming parts, it's quick and easy.
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.
Reads like chatgpt, or those insufferable linkedin autogenerated ai questions:
"How would you secure a system?"
This is the embarrassing bit; this is version 4 of a book that predates ChatGPT by years; knowing that probably most of it is written by humans makes me cringe.
Yes
[dead]