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.
> The purpose is simply to define a minimum baseline of knowledge that every professional software engineer should memorize.
That may be a bit much. It covers a lot (300+ pages just to identify and describe each area of study), and many people can and will go entire careers without needing to know about certain things, and be very effective software engineers (knowing more about compilers is useful in many ways, but by no means required to be an effective programmer in many areas).
I would say it's good for finding gaps in your knowledge in areas that you have contact with, and as a good syllabus if you are branching into something unfamiliar. Would a person be served well by reading through this entirely and at least having been exposed to certain topics once? Yes. Should they necessarily have studied every topic? No. The field is to wide to expect everyone to know everything. This helps with that though, since it lets people identify gaps in knowledge that are currently important that they can then research more.
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.
Oh, yes, I've spent enough time in the PM world to get tired of people justifying their procedures by claiming the PMBOK says it's the correct set of them (the PMBOK explicitly says it's not prescriptive, but it misleads people new people into thinking it is).
If nothing else, the PMBOK is valuable for PMs purely as a reference to the poisonous bullshit that is contained within it? Somewhat like the value of knowing about flat earth hypotheses and believers.
> 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.
"There's already more than enough project management in software teams. "
Given how poorly most software teams are run, I do not think this is demonstrably true.
"Do we also have to emulate the all the turgid rules and mindless checklists that PM's use?"
Programmers have a terrible reputation for refusing to entertain anything outside the process of programming. This kind of comment is emblematic of that mindset.
I think many software engineers could get benefits out of learning some project management skills, but I must say I'm also skeptical of the benefits they'd get from more theoretical knowledge of project management in themselves.
But I also have an immediate reaction to the term "body of knowledge" in the context of PM, which is to reinterpret it as "cargo cult." Hopefully they have something different in mind here, but that's often what it ends up as in practice.
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.
A reference to the Business Analysis Body of Knowledge (BABOK)[1] in the requirements engineering section would have been useful. The BABOK costs around 40 USD.
AFAIR TOGAF is closed source and focuses more on (enterprise) architecture lifecycle management. ISABOK claims to be compatible with TOGAF [0] whatever that means for mere prose.
As an introduction to software development processes I recommend Steve McConnell's Software Project Survival Guide. You can get a used copy for small money.
I would love to hear some reviews of this. This is the first time I’m hearing about this book, but it looks like the exact kind of thing I’ve wanted for a long time.
It's a worthy goal, but this Guide is a strange document. It's only 335 pages long, yet rather than just presenting an outline of the subject and referring to other sources for detailed treatments, it also tries to present some basic knowledge for each topic itself.
It's hard to see how even the most expert contributors and skilled editors could compress a whole industry of knowledge that much and end up with something useful. Inevitably, much of the specific knowledge presented in the Guide is simplified to the point of arguably being wrong, dated to the point of arguably being obsolete, or just missing the point altogether.
As someone else pointed out, this is only a "guide to" the field of software engineering. It does cite additional references as well (details in appendix C), though there are only 36 references supporting the entire Guide and some of them are old and of debatable relevance to modern software development. This edition of the Guide is nearly a decade old now, so it obviously doesn't include references to good books that have been published more recently and adopt a more objective, evidence-led style when discussing which modern practices actually work that was sorely lacking in most books from a decade or two ago.
It should give enough leads for further investigation though; you can yeet any of the headings into Google and get thousands of results and dozens of book references.
+1 it feels like this or something similar could potentially speed up initial steps of picking up new skills by providing "the right term to google for".
In particular, it feels like it targets that stage of problem solving where I've defined my problem and am looking for prior art, but am having a trouble searching simply because I don't know what the people who previously met this problem called it.
For this particular step of problem solving a very broad, very shallow general outline of the whole field, or even just a glossary of terms that tries to cover the whole field, feels like just the tool for the job.
I don't see anything wrong with that book. It is covering very broad scope and maybe if you would want to know why building software is complex and you don't have any knowledge in the topic that would be a good starting point.
Like if you would be an owner of a gym chain and because of current situation you would like to start software company. This could give you an idea why it is not just having "an app idea" and why those pesky developers demand so much money.
I like this part in the book:
Most people are limited in their ability to hold complex structures and information in their working memories, especially over long peri- ods of time. This proves to be a major factor influencing how people convey intent to com- puters and leads to one of the strongest drives in software construction: minimizing complex- ity. The need to reduce complexity applies to essentially every aspect of software construction and is particularly critical to testing of software constructions.
I think that providing a wide (vs deep) overview of software development is interesting & valuable. It's useful for newcomers, but also for people exploring new areas of IT. IMHO it's easier to dive into the details once we have at least a bird's eye view. But I'm a generalist so I'm probably biased ;-)
Being aware of ideas, concepts & terms helps a ton to create clear mental models, find solutions more efficiently and reduce tunnel vision (e.g., John Doe works on back-end and thinks that front-end development is simple/easy).
Of course a single book, cannot explain all that much, but I really feel like it's possible to share the main ideas, explain the jargon, what matters and why, what to pay attention to, etc. Readers gain a rough understanding of various ideas, and can come back for more if/when they need to dive into other subjects.
I ran into DMBOK just a few days ago when trying to figure out how to level up my schema-design skills.
It sounds potentially useful as a map breaking down which directions to research in, but based on my research DMBOK also seems potentially much broader and shallower than what I need if what I'm really interested in is just the data modeling / data implementation slice.
SWEBOK doesn't doesn't appeal as much to me personally right this moment, because my software engineering foundation already feels secure. DMBOK and PMBOK on the other hand feel more potentially interesting because they cover adjacent fields, so they feel like they'd be helpful in giving me hooks to grow towards being a "T-shaped" expert.
DMBOK in particular sounds intriguing because my company and team are running into more and more data scalability and queryability challenges. I'm no stranger to day-to-day data modeling and schema building as it applies to webapps, but data modeling is something I've never had any formal training in, so I suspect my solutions tend to be only naively mature. I'm probably currently sitting in the Dunning-Kruger valley of data modeling.
At the same time, DMBOK is intimidating because it's only available as a giant paper tome. I am a minimalist and am worried about the space on my bookshelf.
I'd appreciate any impressions you can give if you've used it in the past. Curious about the other DAMA publications as well.
I started reading DMBOK, it's quite detailed as you describe. It's more of a reference in my opinion though.
It can be a nice exercise to read through it with a group at your company. Have people relate to what is stated in the book to create actionable goals.
Thanks! To pick your brain... did you approach mostly the data modeling / data security / other slices more closely related to software engineering, or did you also socialize it out and get other people and teams involved in other slices like data governance?
Can you speak to your specific situation at the time and any specific takeaways?
More nitty-gritty... any suggestions for how to read through as a group in remote work? Feels like the only way might be to get each person a copy...
We read it cover to cover (this was a mistake as the book is just way too long). We usually covered a chapter in each meeting. I recommend picking one or two chapters that you need to focus on. They also have a shorter version that was released a couple of years ago you might want to look at first.
Every meeting started with five minutes of writing on post-it notes how the contents of the chapter related to us (6-10 people in each meeting). Each person then put their post-it notes on a whiteboard. We had several categories to put the notes into (like "good"/"bad"/"how to apply"). This encourages people to read as they need to actively participate and contribute in the discussion. However, this book is not for everyone, some will definitely find it boring and dry. I think it is more fun the deeper you are involved in data related issues.
The end of the meeting consisted of us summarizing the results to see if people were experiencing the topic similarly. We had several stakeholders in the reading group and they were from different siloes in the enterprise. It was nice to see that a lot of the experience was shared and there was general agreement regarding feedback.
One memorable takeaway was the realization that we needed a data dictionary. That eventually led to a pilot project.
I'm not even sure there's a widely accepted definition of what 'software engineering' is, or what constitutes a 'software engineer'.
I like the idea of having a body of knowledge, but given the loose definitions above, I'm not sure this is useful or practical beyond documenting some potential best practices/techniques.
For a context, some older version of swebok was edited by Steve McConnell, the author of an old best seller "Code Complete" At that time, there was some consensus on what's software engineering. This version (coming out at 2013) was extension of that line of thought.
The IT field has expaneded since then. So your point is kinda right: I don't think SWEBOK covers mobile or ML fields well, for example. But there is a still some value to cover traditinal software engineering field, as it still exists and it's not that small.
To each his own, but I found that book to be badly written, outdated, and not applicable to my day-to-day work.
Published in 2006, it feels like it was written for a mid-90s world of waterfall process and shrink-wrapped software (6-month death marches to immovable ship dates). No mention of agile methods or the idea that web applications might be developed and deployed differently. It plays upon Dilbert-esque stereotypes of managers and marketing folks, and assumes a 100% adversarial relationship between the brilliant programmers and everyone else.
Maybe I've just been lucky, but this isn't at all representative of the world I live in. I guess I'm fortunate not to have to adopt such a cynical worldview as the author.
Then again, don't take my word for it, I only read half the book before I put it back into the huge stack of unread books next to my desk.
