What named principles (e.g., information hiding, DRY, etc.) in software development do you find are often referred to but are commonly misunderstood (or are actually flawed)? I have a talk, Principle Misunderstandings, where I cover a few, but I'm planning to extend this to half- and full-day formats, so I'd be interested in what you find is commonly misunderstood.

@kevlin Oh where to start?

TDD/BDD (obviously-both terms seem to have morphed into “We have some random, impenetrable tests”)
Automated Testing
10 minute build
Continuous Integration (but still using Feature Branches & long lived branches)
Shift left (so many folks assume this means “in the pipeline”)
Build once (most don’t)
Dependency Injection
Single Responsibility
Open Closed
(actually, all of SOLID!)

I'm sure you will find plenty of other material 🙂

@thirstybear @kevlin

+ "refactoring" but where it changes behaviour, too.

@stevefenton @kevlin One more that I see everywhere:
Code Review (in context of PRs. It seems to have morphed into “I have no idea what this change is supposed to do but it looks good to me”)

@thirstybear @stevefenton @kevlin

the universal automatic rubber stamp

call it ZFQA

@kevlin
Single Entry Single Exit (SESE). A college tried to tell me once it means you can not have multiple return statements per function.
@xris Interesting, I was just contemplating whether or not to tackle that one this morning! Thanks for the reinforcement.

@kevlin @xris this has been encouraged by MISRA C. *Much* auto code is marred by it.

@PeterSommerlad took a deep dive on this. IIRC, conclusion was it dates back to pre-structural era: don't jmp into/out of the middle of a procedure. It was then adapted by MISRA as a rule for ensuring mid-function `free`s never got skipped.

@JSAMcFarlane @kevlin @xris

SESE stems from a time as a principle of structured programming. all current languages with call-return semantics follow it. so a procedure is already following SESE. That safety guidelines translated SESE to a single return statement is BS from people not knowing its origins. We filed a change request for against one of the ISO safety standards and abandoned single return requirements for MISRA-C++

@PeterSommerlad
@JSAMcFarlane
Wow. Did not know this BS got into MISRA. Thanks for the elaboration.

@xris @JSAMcFarlane

the source is not MISRA but IEC/EN 61508-3 and ISO 26262 safety standards that mutated SESE to "single return statement per function" without understanding the implications of either. IMHO single return statement makes code more complex and thus more error prone. Therefore we fought to get rid of it.

@PeterSommerlad @xris @JSAMcFarlane and the real fun thing about single return statement is that you almost always have to introduce a goto. I'm not Dijkstra, but I still avoid goto like the plague, it can introduce all kinds of stupid side-effects (and yes, a "finally" or "defer" is just a goto in disguise).

@[email protected]

  • Minimum viable product (I suppose isn't strictly software related, but seems to see most use and misuse in our industry).
  • CI has been misused so much that in general usage it now just means 'having a build server and a main branch' and I have, to my shame, used it to mean that on my CV before.
  • Unit tests, integration tests, pretty much anything with test in the name (cries slightly).
  • IoC and dependency injection: not so much misunderstood, as known to not be understood because it has something to do with containers and reflection and framework plugin configuration and magic rather than knowing "but why?" on any level
@[email protected] Oh! And "UX". The idea it could also mean something easy and/or efficient to use rather than just "visually shiney". Is that software? I feel like that's at least software adjacent.
@kevlin I seem to remember @jasongorman looking at a sample of claimed "TDD" repositories and finding dramatic percentage where tests were added after the code.
@kevlin Happy to brainstorm at ACCU. Sounds like fun!
@kevlin Liskov Substitution Principle (LSP). People think it means a subtype can’t reject a message by throwing an exception, when permitted by specification, like Java’s unmodifiable collections. In fact Liskov’s original paper has an example of a subtype throwing an exception in response to a message it doesn’t support.
@stuartmarks Could you clarify where she says this? This is not my understanding of the original paper.
@kevlin OK. Vacationing now. Will follow up with citations and quotes in a couple days when I’m back at my desk.

@kevlin The citation is to the Liskov paper that everybody cites, which I believe is the first one that talks about hierarchy and inheritance:

Liskov, Barbara. Data Abstraction and Hierarchy. ACM SIGPLAN Notices V23N5, October 1987, Addendum to the OOPSLA 1987 Proceedings. https://dl.acm.org/doi/10.1145/62139.62141

For convenience, the oft-quoted section that introduces the notion of substitution is the first paragraph of 3.3, “Type Hierarchy”: (1/6)

«A type hierarchy is composed of subtypes and supertypes. The intuitive idea of a subtype is one whose objects provide all the behavior of objects of another type (the supertype) plus something extra. (2/6)
@kevlin
«What is wanted here is something like the following substitution property [6]: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.» (3/6)
@kevlin
The next couple paragraphs cover examples of types that are not subtypes of each other, such as lists and sets or stacks and queues. The paper continues with a couple examples of subtype hierarchies, the first being indexed collections, followed by this: (4/6)
@kevlin
«The second example is abstract devices, which unify a number of different kinds of input and output devices. Particular devices might provide extra operations. […] Another possibility is that abstract devices would have all possible operations, e.g., both ‘put_char’ and ‘get_char’, and thus all subtypes would have the same set of operations. (5/6)
@kevlin

«In this case, operations that not all real devices can do must be specified in a general way that allows exceptions to be signalled. For example, ‘get_char’ would signal an exception when called on a printer.»

A printer throwing an exception in response to ‘get_char’ is similar to a Java unmodifiable collection throwing an exception in response to a mutation method. (6/6)
@kevlin

@stuartmarks Ah, OK, I was familiar with this section and conclusion, but I realise now I misread your original post.

I had assumed that you were saying exceptions were unconditionally OK, whereas I now see you carefully stated — and I overlooked — "... when permitted by specification", which naturally leads to covariant exception substitution.

In which case, yes, we are definitely agreed on this interpretation! Thanks for taking the time.

@kevlin the principle of least privilege is often used as a reason to block read access to every last repo/ticket/document etc. until a IT access request is completed. Interpreted this way, the WWW is the biggest violator of PoLP in history.😂
@kevlin
Agile... but maybe enough talks have been spun on that?
@ami I have certainly contributed a few talks to the "That's not what Agile means" genre 🙃

@kevlin the most common I see misunderstood ist, Model-View-Control, although not really a principle, is it?

The confusion stems mostly from the naming convention of naming business logic processing classes as 'controller'. Since most frameworks handle both view and control, and most devs never implemented input devices, 'control' is very unintuitive.
Even big companies confuse this (i.e. Microsoft as documented in their MVVC documentation, for example)

@kevlin
KISS. I had a colleague once who thought simplicity means to hard-code values into our scripts, instead of using constants or configuration files.
@dermojo Oh yes, I've seen this before 🤦‍♂️

@kevlin
“short functions”: in the original paper it was “not more than 100 lines” which got reduced to “should fit on one screen” (which was 80×25 back then). Ans then suddenly people started to break up 5 line functions.

And everything that is wrong with the clean code book.

@Lapizistik Which 'original paper' did you have in mind?

@kevlin

I tried to find the original document in a quick search, but did not succeed. If I remember correctly it was some ALGOL or FORTRAN document from the 1960 or something (not a reference manual but a document discussing how to write code). I'd say Bell Labs, but I am not sure at all.

@kevlin "Fail fast". This can mean a number of things depending on who you ask. A project manager will give you a totally different answer from a programmer, and even programmers amongst themselves aren't really sure what "fail fast" is supposed to mean.