Thanks for that. Had a quick cursory glance and randomly spotted this gem: 'The arsenal of OSs is abstraction'. It sounds debatable, but it's probably correct lol
I did not know of this document before today. I think it's valuable and I'm glad the link was shared.
The value for me, I think, will be this.
I'm an older (61) software engineer. A document like this can serve as a starting point for discussion in the software group of which I am a member. It can be something like a reference design for software practice within the group.
By reference design, I mean, something that the group considers or consults when discussing or designing how its own practices should be.
I'm thinking about facilitating some short (15 minute) discussions within our group to introduce the document and its contents, and then see if people think it would be worth our time to consult it when designing our own policies and procedures.
The purpose is simply to define a minimum baseline of knowledge that every professional software engineer should memorize. It's kind of like having a common vocabulary so that we can hold productive discussions rather that wasting time defining basic terms. It isn't intended as a guideline to follow in daily work.
Yeah, it's definitely not gonna be that explicit. There's a section under Cover called "Introduction to the Guide" that explains their objectives.
Anyways, this doc is gonna be useful for me because while I took computer science & engineering as a major in college, I never ended up taking a course that taught me how to holistically look at software engineering as a discipline and all the terms that come with it.
The SEBOK is really for setting the stage, agreeing to practices and framing approach to the problem.
All good stuff to ensure as a baseline for people working on projects you're on. Working with someone on a project that can't sort a requirement from a spec can be problematic.
I think it's a great read.
Analogous to this is the PMBOK which is required reading for PM certifications.
Not attacking this association, but just wanted to say I really dislike the term "body of knowledge".
Areas of knowledge are certainly some kind of 'body', but the term always sounds to me like something you just keep adding more stuff onto the outside as you go, like a big snowball of ideas. And knowledge can become defunct, irrelevant, or disproven over time.
And there's something about the way it tries to sound almost authoritative, without claiming to be scientific.
I suspect the inspiration for the title is the very well regarded "Project Management Body of Knowledge" document maintained/published by the PMI.
People in the industry refer to the PMBOK ("Pimbock") pretty frequently. There are lots of people in big-time project management that disdain aspects of the PMI (including and especially the PMP certification, which is often re-named as "pretty much pointless"), but the PMBOK is a valuable document -- ESPECIALLY for people new to the field.
We could do worse, in software, than to emulate that particular success.
> "I suspect the inspiration for the title is the very well regarded "Project Management Body of Knowledge" document maintained/published by the PMI."
While that's not impossible, it must be noted other STEM organizations that predate the PMI have their own "body of knowledge" definitions, for example:
The PMBOK is in it's 6th Edition with a 7th expected this year. It is also a 756 page document at the moment.
I look forward to seeing the SWEBOK also improve over time.
Also, I'm not sure why some of the comments fail to acknowledge the benefit of having a collection of best practices intended to be tailored for each individual use case. That's what the PMBOK is and how it is used when used properly.
The PMBOK is a very good source for your vocabulary searches. But, especially for people new to the field, it's an incredibly harmful document. And the harm is entirely caused by the "it misleadingly looks authoritative while it's not and really shouldn't be" issue the GP stated.
> We could do worse, in software, than to emulate that particular success.
Perhaps, but couldn't we could do better instead?
There's already more than enough project management in software teams. Do we also have to emulate the all the turgid rules and mindless checklists that PM's use?
I suspect this is yet another attempt at forcing software engineering workflows into something that's more compatible with PM mentality. Or possibly to commoditize the practice of software engineering. IMHO, it's just a different kind of crack for some management consultants to offer to their c-suite clients.
I think this is why the PDF is actually the "Guide to the Software Engineering Body of Knowledge". It's not a representation of the complete body of knowledge itself, but extracting key concepts and terms and provides pointers to things that are most relevant. If things are irrelevant or disproven over time, the guide to the body of knowledge would remove those terms, concepts, or references and point to something else.
It actually apes the Project Management Institute's terminology exactly. The PMBOK guide and the PMBOK are the same thing (as far as I know). This takes exactly the same approach. The guide is the entire book, it just has a funny name as if there was another larger book that this is a guide to. There isn't.
Unfortunately, where it does present "key concepts and terms", that presentation is often flawed. I think it would be more useful as a guide to the field of software engineering if that's the only thing it tried to be, setting out a well-considered structure but then referring to other reliable sources for details. It could be a lot shorter and more accessible, and it wouldn't keep saying things that are misleading or incorrect.
I'm thinking of a distinction between eg body of knowledge to mean the arrangement of muscle, skeleton and organs, versus a corpus of knowledge that you presume to be a representative collection of body parts making up a adequate whole.
> knowledge can become defunct, irrelevant, or disproven over time.
True, but at the same time, old software is still around; if you can look up the terms and practices from 'back when' using an overview like this, or at the very least have enough broad knowledge to recognize what it is, you're already ahead.
I've only skimmed it (the PDF is linked elsewhere), but it looks like just the resource for a professor of software engineering and -design to have and become acquainted with - know a little about a lot of things, then go from there.
Maybe. I've worked in the defense industry in and around software as a developer, designer etc for around 30 years. There's some good detail in there, but i think it's a little dated. Try looking for any material on REST in there. If it got refreshed somewhat i'd have it on my virtual bookshelf for sure.
Ah, good old SWEBOK. There's a bit of history to this document. Most of us who started our careers in the last decade came up in a time of agile programming. Where code comes first and documentation is mostly just done before prod releases. The programming world wasn't always like this.
The software engineering world has a pendulum that swings between "strict process" and "just write code", and right now we're pretty far into the just writing code camp.
SWEBOK captures a lot of the push in the late 90s, early 2000s to make software engineering a licensed profession. Where most of the work would be done in UML diagrams and committees before any code was written. The thinking was that if the diagrams were thorough enough that the coding part would be trivial, almost like how blueprints are for building a house.
And then everyone realized that the blueprints for the house are not the UML diagrams, but the code itself. Documentation is done at the same time as the code is written, because the code itself is the authoritative documentation about how to build the program and what it will do.
If the pendulum does swing back, let's hope those strict processes operate on code this time, instead of on silly code-adjacent time-wasting activities.
The problem with this response is that the the "code itself" is not the authoritative documentation of what should be done. The "code itself" is what was done and could be absolutely, completely wrong.
The point of separating documentation and code is that the assumption is that the documentation (design) is correct, having been reviewed and the code should implement it correctly, correctness being verified by review and testing.
Those strict processes should absolutely operate on code, but they are useless if they operate only on the code.
As someone who tends to conceptualise code visually, I find it extremely helpful to sketch-out diagrams of the processes and organisation before getting anywhere near the keyboard -- drawing clarifies my thinking unlike anything else. As such, I find the top-down UML-first approach to be much more natural, but I seem to be in the minority on this.
I often find myself recommending and sharing this. Nice to see it on the front page. It's something that other engineering professions often share, a guide to the state of the art; pointers to find out about the different practices and tools we use.
Readit News
Dead Comment
The value for me, I think, will be this.
I'm an older (61) software engineer. A document like this can serve as a starting point for discussion in the software group of which I am a member. It can be something like a reference design for software practice within the group.
By reference design, I mean, something that the group considers or consults when discussing or designing how its own practices should be.
I'm thinking about facilitating some short (15 minute) discussions within our group to introduce the document and its contents, and then see if people think it would be worth our time to consult it when designing our own policies and procedures.
Thoughts?
For example it talks about design patterns but only in an abstract way, not what pattern could help you solve certain classes of problems (2.3.3).
Or API design, great that's a constant source of contention, again, nothing meaty to reference in a discussion either (2.4.1).
I'm probably grossly misunderstanding the purpose of that document. I was hoping it to be more similar to the OWASP cheat sheets [0] but more general.
[0] https://cheatsheetseries.owasp.org/
Anyways, this doc is gonna be useful for me because while I took computer science & engineering as a major in college, I never ended up taking a course that taught me how to holistically look at software engineering as a discipline and all the terms that come with it.
All good stuff to ensure as a baseline for people working on projects you're on. Working with someone on a project that can't sort a requirement from a spec can be problematic.
I think it's a great read.
Analogous to this is the PMBOK which is required reading for PM certifications.
Deleted Comment
Areas of knowledge are certainly some kind of 'body', but the term always sounds to me like something you just keep adding more stuff onto the outside as you go, like a big snowball of ideas. And knowledge can become defunct, irrelevant, or disproven over time.
And there's something about the way it tries to sound almost authoritative, without claiming to be scientific.
People in the industry refer to the PMBOK ("Pimbock") pretty frequently. There are lots of people in big-time project management that disdain aspects of the PMI (including and especially the PMP certification, which is often re-named as "pretty much pointless"), but the PMBOK is a valuable document -- ESPECIALLY for people new to the field.
We could do worse, in software, than to emulate that particular success.
While that's not impossible, it must be noted other STEM organizations that predate the PMI have their own "body of knowledge" definitions, for example:
- https://www.nspe.org/resources/licensure/resources/professio...
- https://www.asce.org/civil_engineering_body_of_knowledge/
- https://www.iise.org/details.aspx?id=43631
I look forward to seeing the SWEBOK also improve over time.
Also, I'm not sure why some of the comments fail to acknowledge the benefit of having a collection of best practices intended to be tailored for each individual use case. That's what the PMBOK is and how it is used when used properly.
Perhaps, but couldn't we could do better instead?
There's already more than enough project management in software teams. Do we also have to emulate the all the turgid rules and mindless checklists that PM's use?
I suspect this is yet another attempt at forcing software engineering workflows into something that's more compatible with PM mentality. Or possibly to commoditize the practice of software engineering. IMHO, it's just a different kind of crack for some management consultants to offer to their c-suite clients.
https://www.pmi.org/pmbok-guide-standards/foundational/pmbok
https://en.wikipedia.org/wiki/Corpus_Juris_Civilis
True, but at the same time, old software is still around; if you can look up the terms and practices from 'back when' using an overview like this, or at the very least have enough broad knowledge to recognize what it is, you're already ahead.
I've only skimmed it (the PDF is linked elsewhere), but it looks like just the resource for a professor of software engineering and -design to have and become acquainted with - know a little about a lot of things, then go from there.
Deleted Comment
The software engineering world has a pendulum that swings between "strict process" and "just write code", and right now we're pretty far into the just writing code camp.
SWEBOK captures a lot of the push in the late 90s, early 2000s to make software engineering a licensed profession. Where most of the work would be done in UML diagrams and committees before any code was written. The thinking was that if the diagrams were thorough enough that the coding part would be trivial, almost like how blueprints are for building a house.
If the pendulum does swing back, let's hope those strict processes operate on code this time, instead of on silly code-adjacent time-wasting activities.
The point of separating documentation and code is that the assumption is that the documentation (design) is correct, having been reviewed and the code should implement it correctly, correctness being verified by review and testing.
Those strict processes should absolutely operate on code, but they are useless if they operate only on the code.
You can find the PDF via your favourite search engine.