Software development gets passed down as an oral and written history of mistakes and learnings — and we wind up with a lot of "rules of thumb". Some of them are not as universally useful as some make them out to be. What are they?
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (26)
I'll start by saying that DRY (don't repeat yourself) is not entirely untrue, but an over-simplification to the point of harm as a principle.
Stop Writing DRY Code
Dylan Anthony ・ Apr 5 ・ 7 min read
Some conflicting ideas with DRY is the law of leaky abstractions and the rule of three which both definitely encourage skepticism of mismanaged attempts at DRY.
I think DRY means well, but IMO is often used harmfully as an idea.
Repetition is always better than the wrong abstraction.
It took me a while to realize this but 100%
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
YAGNI is a good idea to have in mind, but I see it being used by grumpy programmers who want to win an argument.
"You aren't gonna need it" (YAGNI) is a principle which arose from extreme programming (XP) that states a programmer should not add functionality until deemed necessary. XP co-founder Ron Jeffries has written: "Always implement things when you actually need them, never when you just foresee that you need them." Other forms of the phrase include "You aren't going to need it" (YAGTNI) and "You ain't gonna need it" (YAGNI).
You can't just pull from a rule of thumb to win an argument against your PM. Have a real conversation.
"Code should be written so that the most junior developer can understand it."
What utter BS
In the extreme it's important in environments where "developer fungibility" is valued.
In the best case it's motivated by the reasonable desire to minimize the bus factor in the worst case it's a sign of a culture of assembly line coding.
That said, if you have trouble understanding code you wrote three months ago perhaps it's time to dial things down a bit - it can be a tricky balance.
The saying is utterly dependent on the quality of your most junior developer :-)
DRY has been mentionned, so here would be the second: "When you have a hammer, everthing is a nail".
Some new tech actually needs an exploratory phase where, yes, you have to consider everything as a nail—until you figure out what is and what isn't. It's easy to come 10 years after everything has been figured out and say "You never needed React/Blockchain/Saas etc.".
But without prior knowledge, you need to hammer blindly at some point. Who would have though we would have email in the browser for sending large files? Well, have with your FTP then…
That's a really interesting take. I'd say some of the problem arises when so many people are trying to profit too early during the exploratory phase. A lot of hammer salesmen selling in to all the wrong markets and seeking a quick markup on their hammer investment.
Yeah, I agree indeed, some of this marketing bs is tiring indeed. But a lot of stuff is done because randomly try things for no reason. The hammer was most likely invented before the nail… :p
This literally doesn't answer the question, but a really tremendous principle I was thinking about recently is "Principle of least surprise" — it's not prescriptive enough to be overbearing, but really has empathy for other developers and/or users baked in.
What an audience finds astonishing relates their background and general familiarity. So the principle only works relative to an implied audience which makes it somewhat subjective.
Maybe "Avoid Premature Optimisation". Like all these principles, they're well meaning and well founded but traps lurk within. It's easy to reach a stage where retrofitting the optimisation by the time that it's proved that it's actually needed is WAY harder than if it had just been planned in from the start.
Good point ... I think you need to think about it and plan for it, but not always implement it right away.
Single Responsiblity Principle (SRP):
"Gather together those things that change for the same reason, and separate those things that change for different reasons… a subsystem, module, class, or even a function, should not have more than one reason to change."
Kevlin Henney Commentary
All of them. As part of the human learning process, we all tend to take something that worked out well in one scenario and try it on everything. In the small and the large. That's when you see posts extolling only the virtues of a new (to the author) tech or strategy. Examples: DRY, microservices. Then many people try it and are plagued by undiscovered downsides. Then they post articles condemning it. Eventually we gain a cultural understanding of where it fits and where it doesn't. That's what the Gartner hype cycle is meant to measure. And often the corpus of articles on a given topic indicates where we are with it.
Don't reinvent the wheel.
I know that it probably exists a package or library that does it better, faster, it's tested and maintained... but what if I don't want a new dependency? What if the library introduces more bloat than I want to accept? What if I'm trying to learn?
I think it's acceptable to reinvent the wheel when you don't like the wheels you find.
Yes. Pretty sure that if "The wheel" is "websites" - that we need be reinvestigating them a bit.
"Clean code".
People assume that the process for "clean code" is "code should be clean from the moment you try to make it work to the end". No. The very principle of clean code is "make it work, even if the code is crap. Then, once it works as you'd expect, then change it to make it clean"