[HN Gopher] Software Engineering Body of Knowledge
___________________________________________________________________
Software Engineering Body of Knowledge
Author : p1necone
Score : 217 points
Date : 2021-04-22 10:25 UTC (12 hours ago)
(HTM) web link (www.computer.org)
(TXT) w3m dump (www.computer.org)
| veltas wrote:
| 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.
| ubermonkey wrote:
| 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.
| marcosdumay wrote:
| 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.
| ubermonkey wrote:
| I'm going to guess you haven't spent much time in the PM
| world if you think the PMBOK is harmful to new people
| instead of educational.
| jtdev wrote:
| 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.
| marcosdumay wrote:
| 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).
| r00fus wrote:
| Got an example where PMBOK led someone astray?
| crispyambulance wrote:
| > 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.
| ubermonkey wrote:
| "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.
| crispyambulance wrote:
| > Given how poorly most software teams are run, I do not
| think this is demonstrably true.
|
| OK, but one does not "fix" organizational problems by
| adding more layers of PM.
| ThrowawayR2 wrote:
| > " _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:
|
| - https://www.nspe.org/resources/licensure/resources/professi
| o...
|
| - https://www.asce.org/civil_engineering_body_of_knowledge/
|
| - https://www.iise.org/details.aspx?id=43631
| Cthulhu_ wrote:
| > 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.
| benjaminjosephw wrote:
| This sounds like a fair description of how software engineering
| and computer science has progressed over the years so maybe
| it's a fair term ;)
| sas224dbm wrote:
| 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.
| kper wrote:
| I think it comes from the latin word 'corpus', which also means
| body. This wording came from the romans.
|
| https://en.wikipedia.org/wiki/Corpus_Juris_Civilis
| veltas wrote:
| That actually makes me feel better, and is quite interesting,
| thank you.
| TomOwens wrote:
| 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.
| Silhouette wrote:
| 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.
| Cullinet wrote:
| 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.
| LegitShady wrote:
| 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.
|
| https://www.pmi.org/pmbok-guide-standards/foundational/pmbok
| NAR8789 wrote:
| tangential: Has anyone read DMBOK and what's your impression of
| its usefulness for software engineers?
| https://www.dama.org/cpages/body-of-knowledge
|
| 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.
| haffi112 wrote:
| 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.
| NAR8789 wrote:
| 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...
| rwoerz wrote:
| Somewhat related (but with focus on architecture):
| https://itabok.iasaglobal.org/
| manishsharan wrote:
| For architechture, would you not prefer the TOGAF documentation
| ? you will get a useful certification out of it once you pass
| those tests.
| rwoerz wrote:
| 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.
|
| [0] https://itabok.iasaglobal.org/itabok3_0/engagement-model-
| ove...
| stakkur wrote:
| 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.
| flakiness wrote:
| 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.
| whereis wrote:
| Maybe this (and other work) will eventually lead to a
| Professional Engineering standard for software dev
| okl wrote:
| There's also a PMBOK (project management)
| https://www.pmi.org/pmbok-guide-standards
|
| You can find the PDF via your favourite search engine.
| [deleted]
| sirsinsalot wrote:
| A gem from the back of the book about staying current: "This
| article was obsolescent the moment it was drafted."
|
| Software.
| dejj wrote:
| 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.
|
| [1] https://www.iiba.org/career-resources/a-business-analysis-
| pr...
| okl wrote:
| 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.
| pcbro141 wrote:
| Direct PDF link: https://ieeecs-
| media.computer.org/media/education/swebok/swe...
| drummer wrote:
| Lol thanks, came here to ask exactly this.
| de6u99er wrote:
| ty
| cyberlab wrote:
| 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
| DogWithKeyboard wrote:
| Thanks!
| agentultra wrote:
| 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.
| jes wrote:
| 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.
|
| Thoughts?
| [deleted]
| barbazoo wrote:
| I only skimmed it and I couldn't find anything practical enough
| that would help me in my day to day work.
|
| 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/
| deeteecee wrote:
| 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.
| r00fus wrote:
| 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.
| nradov wrote:
| 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.
| kbenson wrote:
| > 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.
| auslegung wrote:
| 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.
| ozim wrote:
| For me there is no practical value.
|
| 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._
| Silhouette wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| NAR8789 wrote:
| +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.
| getaclue wrote:
| good overview
| [deleted]
| emddudley wrote:
| The current revision, V3, was published in 2013.
| nitramm wrote:
| Knowledge from which chapter to you consider the most useful for
| your work?
| getaclue wrote:
| depends on the project/place entire work is useful
| postfacto wrote:
| A truly worthy book of Software Engineer Dark Arts that's come in
| handy multiple times.
|
| The Career Programmer: Guerilla Tactics for an Imperfect World
| (Expert's Voice)
| https://www.amazon.com/dp/1590596242/ref=cm_sw_r_cp_api_glt_...
| NtochkaNzvanova wrote:
| 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.
| getaclue wrote:
| nice share of the doc pretty common
| playpause wrote:
| Where did the amazing comment from itssatireok go? Was it deleted
| by them or moderators?
___________________________________________________________________
(page generated 2021-04-22 23:01 UTC)