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 Premature Optimization
@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 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 Happy to brainstorm at ACCU. Sounds like fun!
@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.
- 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
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.
@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 🙂
+ "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”)