Discussion
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 "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.
@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?
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 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.
@[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”)
Install bonfire.mavnn.eu
Get the full app experience
