13 ms·

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

205 points by bsoles 2y ago

beryilma 2y ago
> 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.
kragen 2y ago
It's so unfortunate that this effort is still alive. The ACM canceled its involvement for excellent reasons which are worth reading: https://web.archive.org/web/20000815071233/http://www.acm.org/serving/se_policy/bok_assessment.pdf https://web.archive.org/web/20000815071233/http://www.acm.or... It's probably also worth reading Dijkstra's assessment of the "software engineering" field (roughly coextensive with what the SWEBOK attempts to cover) from EWD1036, 36 years ago. > Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.". https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF The ACM's criticisms, however, are much harsher and much more closely focused on the ill-conceived SWEBOK project. The IEEE's continued involvement calls the IEEE's own credibility and integrity into question—as do its continued opposition to open-access publishing and its recent history of publishing embarrassingly incompetent technical misinformation in IEEE Spectrum (cf., e.g., https://news.ycombinator.com/item?id=41593788 https://news.ycombinator.com/item?id=41593788, though there are many other examples). What is going on at IEEE?
- deleted 2y ago
  [deleted]
- michaelsbradley 2y ago
  Any suggestion for a handbook or compendium that you consider to be a worthy alternative?
  - kragen 2y ago
    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 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/ 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.
ctz 2y ago
Runtime errors surface when a program runs into an unexpected condition or situation such as dividing by zero, memory overflow, or addressing a wrong or unauthorized memory location or device, or when a program tries to perform an illegitimate or unauthorized operation or tries to access a library, for example. The programs must be thoroughly tested for various types of inputs (valid data sets, invalid data sets and boundary value data sets) and conditions to identify these errors. Once identified, runtime errors are easy to fix. Embarrassing horseshit.
- dustfinger 2y ago
  > 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.
  - TrueDuality 2y ago
    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.
    - dustfinger 2y ago
      I understand that is what they meant, but it is not what they wrote. They should have qualified the statement as you did, with the conditions that yield a runtime error. Even if they generalized those conditions that would have been fine. for example: or tries to access a library that it is unable to for some reason without handling the resulting error.
pnathan 2y ago
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!”
- numbsafari 2y ago
  Even he admits, he had to start somewhere.
  - pnathan 2y ago
    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.
kazinator 2y ago
> Popular OOP languages include C++, C#, Cobol 2002, Java, Python, Lisp, Perl, Object Pascal, Ruby and Smalltalk. :)
JanSt 2y ago
If you really want someone interested in software development to run away, hand them books like this one.
- NotGMan 2y ago
  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.
  - epolanski 2y ago
    Software quality may increase though, because there's a desperate lack of solid engineering practices across the industry.
- deleted 2y ago
  [deleted]
- epolanski 2y ago
  This is meant for engineers, a certification-like body of the core knowledge of the field.
tptacek 2y ago
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".
- codetrotter 2y ago
  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.)
- mixmastamyk 2y ago
  Believe it is supposed to be slow-moving, keeping to settled matters. Have those fallen out of favor, or shown to be wrong already?
  - tptacek 2y ago
    I would not describe SWEBOK's breakdown of software security as "settled".
- glwtta 2y ago
  Apparently I am also stuck in 2012 - are we not doing cloud and machine learning anymore?
aste123 2y ago
Yes
miffy900 2y ago
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?
- jcarrico 2y ago
  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.
  - floydnoel 2y ago
    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.
  - globular-toast 2y ago
    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.
    - Kerrick 2y ago
0xbadcafebee 2y ago
There appears to be a lot of hate towards this in the comments (because it's not perfect?), but I feel strongly that we need explicit bodies of knowledge, along with certifications for having been trained on it. Every company I go to, the base of knowledge of all the engineers is a complete crapshoot. Most of them lack fundamental knowledge about software engineering. And they all lack fundamental knowledge about the processes used to do the work. That's not how engineering should work. If I hire an architect, I shouldn't have to quiz them to find out if they understand Young's Modulus, much less teach them about it on the job. But that's completely normal in software engineering today, because nobody is expected to have already learned a universal body of knowledge. I get this thing isn't perfect. But not being perfect isn't a rational argument for not having one at all. And we certainly need to hold people accountable to have learned it before we give them a job. We need a body of knowledge, it needs to be up to date and relevant, and we need to prove people have actually read it and understood it. If this isn't it, fine, but we still need one. (this is, by the way, kind of the whole fucking point of a trade school and professional licensing... why the fuck we don't have one for software engineers/IT, boggles my fucking mind, if this is supposed to be the future of work)
- abtinf 2y ago
  > if this is supposed to be the future of work The day computing becomes subject to professional licensure is the day the field of computing will fall into hopeless stagnation, just like every other such field.
  - lotsoweiners 2y ago
    Maybe that’s not a bad thing…
    - rockemsockem 2y ago
      Let me hear your pro-stagnation argument
      - lantry 2y ago
abtinf 2y ago
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.
epolanski 2y ago
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.
- deleted 2y ago
  [deleted]
- rockemsockem 2y ago
  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.
  - epolanski 2y ago
    To move forward you need a starting place.
osigurdson 2y ago
For me "BOK" is correlated with the creation of false industry and certification.
abtinf 2y ago
A competing and altogether more entertaining and comprehensive body of knowledge: https://grugbrain.dev/ https://grugbrain.dev/
- mckn1ght 2y ago
  Add to that https://github.com/Droogans/unmaintainable-code https://github.com/Droogans/unmaintainable-code
- pnathan 2y ago
  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.
jongjong 2y ago
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.
rockemsockem 2y ago
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.
- wheelinsupial 2y ago
  > 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/ https://ncees.org/exams/fe-exam/ [2] https://ncees.org/exams/pe-exam/ https://ncees.org/exams/pe-exam/ [3] https://www.iise.org/Details.aspx?id=43631 https://www.iise.org/Details.aspx?id=43631 Links to PDFs [4] https://ncees.org/wp-content/uploads/2022/09/FE-Industrial-and-Systems-CBT-specs.pdf https://ncees.org/wp-content/uploads/2022/09/FE-Industrial-a... [5] https://ncees.org/wp-content/uploads/2024/10/PE-Ind-Oct-2020_updated-2024_no-RDS.pdf https://ncees.org/wp-content/uploads/2024/10/PE-Ind-Oct-2020...
TZubiri 2y ago
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 https://youtu.be/pR6z-gm5_cY?t=38&si=F7knCRNcFET7nki7 Anyways, my 2 cents, won't be reading it.
jdlyga 2y ago
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?
- deleted 2y ago
  [deleted]
- eacapeisfutuile 2y ago
  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.
- nradov 2y ago
  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.
rhythane 2y ago
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.
- viraptor 2y ago
  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.
  - globular-toast 2y ago
    What did you do?
    - viraptor 2y ago
      Everything apart from design or software architecture as such. (Unless you include that one weird class on UML and Sybase) Math, electronics, algorithms, encryption, physics, legal side of things like gdpr, networking, compilers, UX, embedded systems, chip design, different CPU architectures, reading research papers, databases (about acid, not specific implementations), ... But the part of "how to manage the process of creating this" and related ideas you were basically supposed to figure out on your own. Or actively ask the teachers. It feels very sink-or-swim now in retrospect. I've never been explicitly taught about testing for example, but if you didn't write them for your projects, I don't think you'd complete them.
ofou 2y ago
this is a list of books mentioned https://www.goodreads.com/list/show/121496.SWEBOK_Consolidated_Reference_List https://www.goodreads.com/list/show/121496.SWEBOK_Consolidat...
T3RMINATED 2y ago
[dead]
mixmastamyk 2y ago
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 https://en.wikipedia.org/wiki/Blind_men_and_an_elephant 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.
elseweather 2y ago
this is a book for people who think the wizard on the cover of SICP is an actual wizard and get scared

205 points by bsoles 2y ago

> 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.

kragen 2y ago

It's so unfortunate that this effort is still alive. The ACM canceled its involvement for excellent reasons which are worth reading: https://web.archive.org/web/20000815071233/http://www.acm.org/serving/se_policy/bok_assessment.pdf https://web.archive.org/web/20000815071233/http://www.acm.or... It's probably also worth reading Dijkstra's assessment of the "software engineering" field (roughly coextensive with what the SWEBOK attempts to cover) from EWD1036, 36 years ago. > Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.". https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF The ACM's criticisms, however, are much harsher and much more closely focused on the ill-conceived SWEBOK project. The IEEE's continued involvement calls the IEEE's own credibility and integrity into question—as do its continued opposition to open-access publishing and its recent history of publishing embarrassingly incompetent technical misinformation in IEEE Spectrum (cf., e.g., https://news.ycombinator.com/item?id=41593788 https://news.ycombinator.com/item?id=41593788, though there are many other examples). What is going on at IEEE?

deleted 2y ago
[deleted]
michaelsbradley 2y ago
Any suggestion for a handbook or compendium that you consider to be a worthy alternative?
- kragen 2y ago
  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 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/ 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.

ctz 2y ago

Runtime errors surface when a program runs into an unexpected condition or situation such as dividing by zero, memory overflow, or addressing a wrong or unauthorized memory location or device, or when a program tries to perform an illegitimate or unauthorized operation or tries to access a library, for example. The programs must be thoroughly tested for various types of inputs (valid data sets, invalid data sets and boundary value data sets) and conditions to identify these errors. Once identified, runtime errors are easy to fix. Embarrassing horseshit.

dustfinger 2y ago
> 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.
- TrueDuality 2y ago
  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.
  - dustfinger 2y ago
    I understand that is what they meant, but it is not what they wrote. They should have qualified the statement as you did, with the conditions that yield a runtime error. Even if they generalized those conditions that would have been fine. for example: or tries to access a library that it is unable to for some reason without handling the resulting error.

pnathan 2y ago

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!”

numbsafari 2y ago
Even he admits, he had to start somewhere.
- pnathan 2y ago
  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.

kazinator 2y ago

> Popular OOP languages include C++, C#, Cobol 2002, Java, Python, Lisp, Perl, Object Pascal, Ruby and Smalltalk. :)

JanSt 2y ago

If you really want someone interested in software development to run away, hand them books like this one.

NotGMan 2y ago
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.
- epolanski 2y ago
  Software quality may increase though, because there's a desperate lack of solid engineering practices across the industry.
deleted 2y ago
[deleted]
epolanski 2y ago
This is meant for engineers, a certification-like body of the core knowledge of the field.

tptacek 2y ago

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

codetrotter 2y ago
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.)
mixmastamyk 2y ago
Believe it is supposed to be slow-moving, keeping to settled matters. Have those fallen out of favor, or shown to be wrong already?
- tptacek 2y ago
  I would not describe SWEBOK's breakdown of software security as "settled".
glwtta 2y ago
Apparently I am also stuck in 2012 - are we not doing cloud and machine learning anymore?

aste123 2y ago

Yes

miffy900 2y ago

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?

jcarrico 2y ago
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.
- floydnoel 2y ago
  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.
- globular-toast 2y ago
  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.
  - Kerrick 2y ago

0xbadcafebee 2y ago

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

abtinf 2y ago
> if this is supposed to be the future of work The day computing becomes subject to professional licensure is the day the field of computing will fall into hopeless stagnation, just like every other such field.
- lotsoweiners 2y ago
  Maybe that’s not a bad thing…
  - rockemsockem 2y ago
    Let me hear your pro-stagnation argument
    - lantry 2y ago

abtinf 2y ago

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.

epolanski 2y ago

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.

deleted 2y ago
[deleted]
rockemsockem 2y ago
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.
- epolanski 2y ago
  To move forward you need a starting place.

osigurdson 2y ago

For me "BOK" is correlated with the creation of false industry and certification.

abtinf 2y ago

A competing and altogether more entertaining and comprehensive body of knowledge: https://grugbrain.dev/ https://grugbrain.dev/

mckn1ght 2y ago
Add to that https://github.com/Droogans/unmaintainable-code https://github.com/Droogans/unmaintainable-code
pnathan 2y ago
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.

jongjong 2y ago

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.

rockemsockem 2y ago

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.

wheelinsupial 2y ago
> 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/ https://ncees.org/exams/fe-exam/ [2] https://ncees.org/exams/pe-exam/ https://ncees.org/exams/pe-exam/ [3] https://www.iise.org/Details.aspx?id=43631 https://www.iise.org/Details.aspx?id=43631 Links to PDFs [4] https://ncees.org/wp-content/uploads/2022/09/FE-Industrial-and-Systems-CBT-specs.pdf https://ncees.org/wp-content/uploads/2022/09/FE-Industrial-a... [5] https://ncees.org/wp-content/uploads/2024/10/PE-Ind-Oct-2020_updated-2024_no-RDS.pdf https://ncees.org/wp-content/uploads/2024/10/PE-Ind-Oct-2020...

TZubiri 2y ago

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 https://youtu.be/pR6z-gm5_cY?t=38&si=F7knCRNcFET7nki7 Anyways, my 2 cents, won't be reading it.

jdlyga 2y ago

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?

deleted 2y ago
[deleted]
eacapeisfutuile 2y ago
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.
nradov 2y ago
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.

rhythane 2y ago

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.

viraptor 2y ago
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.
- globular-toast 2y ago
  What did you do?
  - viraptor 2y ago
    Everything apart from design or software architecture as such. (Unless you include that one weird class on UML and Sybase) Math, electronics, algorithms, encryption, physics, legal side of things like gdpr, networking, compilers, UX, embedded systems, chip design, different CPU architectures, reading research papers, databases (about acid, not specific implementations), ... But the part of "how to manage the process of creating this" and related ideas you were basically supposed to figure out on your own. Or actively ask the teachers. It feels very sink-or-swim now in retrospect. I've never been explicitly taught about testing for example, but if you didn't write them for your projects, I don't think you'd complete them.

ofou 2y ago

this is a list of books mentioned https://www.goodreads.com/list/show/121496.SWEBOK_Consolidated_Reference_List https://www.goodreads.com/list/show/121496.SWEBOK_Consolidat...

T3RMINATED 2y ago

[dead]

mixmastamyk 2y ago

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 https://en.wikipedia.org/wiki/Blind_men_and_an_elephant 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.

elseweather 2y ago

this is a book for people who think the wizard on the cover of SICP is an actual wizard and get scared