DEV Community

Cover image for Beware of excess of "best practices"

Beware of excess of "best practices"

Renan Moura on January 20, 2022

Unlike other disciplines that are more rigid and regulated like Civil Engineering, Software Engineering doesn't have a set of rules to follow by la...
Collapse
 
biomathcode profile image
Pratik sharma

I don't even read documentation. You expect me to read best practises.

Collapse
 
renanmouraf profile image
Renan Moura • Edited

Why spend 5 minutes reading the docs if one can spend hours on trial and error, right?

Collapse
 
ben profile image
Ben Halpern

lol

Collapse
 
cloudkungfu profile image
Javel Rowe

This is the real best practice πŸ˜‚

Collapse
 
wasiqahmdzai profile image
Mohammad Wasiq

Reading documentation can save you hours of debugging.

Collapse
 
drewknab profile image
Drew Knab

Or they're bad docs and they leave you more confused about why your code doesn't work.

Thread Thread
 
nuculabs_dev profile image
Nucu Labs • Edited

Most docs I came across (I read some docs) were good, unless the library/thing was not widely used or old.

Thread Thread
 
miltonsermoud profile image
Milton Sermoud

O-oh, Docker didn't like that.

Collapse
 
gautamjha profile image
GAUTAM JHA

Why reading documentation? when you have 15 days to finish user story.

Collapse
 
tqbit profile image
tq-bit

It's ridiculous to say, but what would actually happen if you suddently went to jail because you didn't do TDD?

If you've read and followed Uncle Bob's practices, you probably know one thing tho.

Rules are there for a reason.

Sure it's unlikely you deploy software that screws up so badly anybody will even notice. Maybe so bad some of your users will sue you over it. Sucks for you, but life goes on.

Myself, I'd rather handle stuff my own way. Which makes it even more important to take special care of QA myself. Assume somebody does blow the internet so bad some day, politicans are forced to take action. And then what?

I don't want some overpaid public advisory board to dictate how to develop stuff.

Making compromises in the team are one thing. But imagine some day there's a governmental rule demanding you to write unit tests. Else - jail. No 95% code coverage? Straight to jail. You use JS on the backend? Gee, that's 5 years min.

Don't get me wrong - I find your point valid. Everyone should use their head during development. Even if one tab is permanently in the ready on stackoverflow.
Just don't forget that when you write code, you hold a certain responsibility towards your stakeholders. And you will be held eligible if you blow it. And if you blow it with the right person, they'll force you to do it their way. Which is likely worse than what you could've come up with yourself (based on the best practices you've read or not)

Collapse
 
joelbonetr profile image
JoelBonetR πŸ₯‡ • Edited

While I understand the motivation of this article, I need to add a disclaimer:

Best practices have a context each.

By this means let's pick a piece of your example to see the reason behind "best practices":

You can spawn a cheap Linux VM and deploy your app by hand instead of spending hours setting up CI/CD for something you can do manually in 2 minutes.

βœ”οΈ Sure you can "spawn" a cheap Linux VM, there's nothing wrong with that nor there's a "best practice" that tells you otherwise. It's perfect for any starting project and many start ups go this path at the beginning. You can even start with a shared hosting and promote it to VM as soon as you need it -unless you need configs or tools not covered in shared hosting plans-.

But the second part... ❌

IRL you'll be wasting more than 2 minutes, because to set it up manually you'll probably need to -let's say- make a production build, pick any FTP tool, make the connection, then find the folder in both sides, push the build to your server, and finally test that it started correctly, let's say 5min at least (being quick).

Building a simple CI script will cost you like... 10 minutes? 15?
You'll amortize the time in just 3 deploys, at this point, from now on you'll be saving time.

The use-case for using CI Scripts instead manually updating your code as best practice not only covers this situation but also any step that you need to add in your pipeline.

Once it's written and tested, adding steps is just typing few characters in the CI script instead manually executing things in sequence.
Think on running some tests before the deploy;

If you do it manually, you'll probably be starring at your screen for some other minutes waiting for them to finish.
If you automate it instead, it's just a yarn test && or npm test && in the middle of your already existing CI script.

Just try to understand at least the basics about what CI and CD are and how they work and apply what you need after analysing your project stage.




TL;DR: Not knowing how to discern which best practices can be applied to your project or to simplify those best practices and apply them to your current use case is something negative for both you and your code and probably for your career as developer as well as it implies that you don't understand those best practices nor the reasons behind them.

Collapse
 
lexlohr profile image
Alex Lohr

Reason is better than rules. If you know the reasons and can reason about them yourself, you will not need the rules.

Collapse
 
highcenburg profile image
Vicente G. Reyes

What's the point of rules if you can just reason out?

Collapse
 
lexlohr profile image
Alex Lohr

Not everyone has enough knowledge that they can, so they need rules as a necessary simplification.

Collapse
 
drewknab profile image
Drew Knab

Because rules can turn into cargo cult dogma. There are plenty of very good reasons not to follow rules that don't fit the project at all or don't fit the project yet.

Thread Thread
 
lexlohr profile image
Alex Lohr

Sometimes, the reasons change, but the rules don't. That's when you get cargo-cult dogma rules.

Collapse
 
grantralls profile image
Grant Ralls

Great take! I was listening to someone recently as I was talking about what I read in "Clean Code". He's a senior engineer. He said "study the book, obsess over writing the cleanest code, then let it go. Realize it's just a tool to solve a problem. It is not the end all be all, that's for you to decide."

Collapse
 
jonrandy profile image
Jon Randy πŸŽ–οΈ

+100

Collapse
 
daverooneyca profile image
Dave Rooney

There are no "best practices", only "good practices in context". Also, Clean Code and Clean Architecture, at least in the circles I travel, aren't considered "bibles". They have some good ideas, but those ideas (and more) are available from other sources.

I also learned XP before Scrum, and I too find the number of meetings onerous. That said, a core tenet of Scrum is "inspect and adapt"... if you're doing Scrum the same way a year after you started, then you aren't doing Scrum! πŸ˜‚ If the meetings aren't providing value, then seriously consider dropping them and finding a different way to accomplish the same goal.

And, related to XP, I don't use TDD all the time for all the things. I do write tests pretty much all the time, but especially when working with legacy code written without test, it can be difficult. When I'm working on fun stuff away from work like Raspberry Pi or Arduino, I often don't write tests at all, though I've been looking at changing that approach.

All that to say that, in the 40 years since I wrote my first line of code, I've realized that there are no absolutes in software development. What is considered a best practice today could be obsolete tomorrow.

Collapse
 
sebbdk profile image
Sebastian Vargr

I agree, we should know why' we do things., and sometimes best practices are not the best practice. :)

But for beginners, I highly encourage them to follow best practices blindly to get used to them. Leave the exceptions to people that have the experience to know when they do not apply. :)

Collapse
 
cyberhck profile image
Nishchal Gautam

If the only reason you do branching and tests because of external factors and not because you know it's the only right thing to do, I dear hope I'm not trusting my information with any of your systems (one can hope)

Collapse
 
cyberhck profile image
Nishchal Gautam

It doesn't take long to setup branching and ci/cd pipelines, tdd helps you execute working code and not run your app to check IF your code is working.

Collapse
 
assertnotnull profile image
Patrice Gauthier

I think the title is misleading here and is kinda a bad advice. Use best practices when they will help you and your team. Or sometimes best practice are part of the framework. Best practices exists for keeping our heads clean when it's the code that is scaling in size. You know where to find things and where to create them.

Just use your judgment when creating a project. Is it one that you just create to learn or one you intend on maintaining for years to come? Good practices help understanding and on-boarding as new developers can use their knowledge to understand the code. If reading code is like reading hieroglyphs everyone loses, even yourself months later when you come back to it.

Designing a system for 50 live users is not the same as for 1 million but using the proper foundation, the language and tooling, can save you lot of work later on. There's no best practice for this. Agile is also not a best practice. It's a tool for project management, you can use as you see fit.

The FOMO is mainly a Javascipt problem called Javascript fatigue. How many packages do you need to learn, install and keep updated? How long and often did you spend testing them making sure they do still work together so your project can run in prod?

Collapse
 
desouzafelipe profile image
desouzafelipe

If the software is mission critical or can cause serious damage to people it is good to learn and implement the so called β€œbest practices” in order to avoid errors, overflow, human fails etc. On the opposite, everybody today wants software shipped as soon as possible, so, we have to balance the use of these β€œbest practices” approaches with the delivery schedule.

Collapse
 
danielbenzie profile image
Daniel • Edited

I agree with the sentiment but I think for a lot of engineers, they are working on small projects that do not ever warrant using these tools. That puts them at a disadvantage when they want to grow. I think following best practices and trying the new tech/methodologies is a trade off worth making even if it is not strictly necessary. After all if it does not work, throw it out.

Collapse
 
jollytoad profile image
Mark Gibson

There is no such thing as "best practice", just the good, the bad and the ugly.

Collapse
 
jkmdroid profile image
jkmdroid

Thats true, choose what suits your project

Collapse
 
josejak profile image
jose_j

Nice

Collapse
 
azeempak profile image
azeempak • Edited

Thanks for sharing your own thoughts not general opinion.... Source

Collapse
 
rolfstreefkerk profile image
Rolf Streefkerk

Best practices relate to a specific context, if that context doesn't really apply than maybe that best practice doesn't apply.