Unlike other disciplines that are more rigid and regulated like Civil Engineering, Software Engineering doesn't have a set of rules to follow by law enforcement.
You won't go to jail if you don't do TDD (Test-Driven Design), or even write tests for your code.
Your system can work just fine if you don't follow any agile method.
You could deploy your next app in a bare-metal Linux machine instead of setting up Kubernetes on a cloud provider to auto-scale your pods, and no one will complain about performance and such.
We have all read Clean Code, Clean Architecture, and some other "bibles" of the software development world which tell us what are the "best practices".
We have all spent hours learning about Scrum or some similar methodology to manage a software project as opposed to old-fashioned cascade-like project management because that's what works "best".
We do tons of meetings, in Scrum alone we have: sprint planning, daily scrum, sprint review, and sprint retrospective.
There are days when I wonder if I attend meetings for a living instead of developing software.
So, what is all this rant about?
It is about not following blindly the so-called "best practices".
I do X because Google does, I use Y because Facebook uses it.
This is a silly reason to do or use anything.
If you are not working with lots of people, in a huge project, with thousands of simultaneous users, following all the "best practices" can be a drawback instead of an advantage.
If you are working alone, in a small app with a handful of users, it is ok to commit directly into the main branch in your GitHub repo.
If your project is not database intensive, or only has to deal with very little data, you can use an embedded H2 database stored directly in your file system and it will work more than fine.
There are projects and teams where it makes sense to follow every single piece of advanced architecture and people management processes there are, but that's totally not the case for your startup of three people.
It is easy to be misled by reading about the latest tech and thinking "everybody is using this", when in fact they are not.
FOMO (Fear Of Missing Out) as a Developer is real and you should be aware of this.
Choose the right tech for the right context in a rational way.
Choose the right project methodology for the right context in a rational way.
You don't have to ditch Scrum in its entirety, you can adapt it and do only 2 of the meetings described instead of all of them.
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.
If your app screen is a simple feature with one text field and a button (like Google's home page), React/Angular/Vue is an overkill.
Learn all of those things, read the books, but use your best judgment to adapt the "best practices" to take advantage of what makes sense to your project and team, and not just because someone else said you should use it.
You also can subscribe to my newsletter.
Oldest comments (30)
I don't even read documentation. You expect me to read best practises.
Why spend 5 minutes reading the docs if one can spend hours on trial and error, right?
lol
This is the real best practice 😂
Reading documentation can save you hours of debugging.
Why reading documentation? when you have 15 days to finish user story.
Or they're bad docs and they leave you more confused about why your code doesn't work.
Most docs I came across (I read some docs) were good, unless the library/thing was not widely used or old.
O-oh, Docker didn't like that.
Nice
+100
Reason is better than rules. If you know the reasons and can reason about them yourself, you will not need the rules.
What's the point of rules if you can just reason out?
Not everyone has enough knowledge that they can, so they need rules as a necessary simplification.
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.
Sometimes, the reasons change, but the rules don't. That's when you get cargo-cult dogma rules.
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)
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.
There is no such thing as "best practice", just the good, the bad and the ugly.
Best practices relate to a specific context, if that context doesn't really apply than maybe that best practice doesn't apply.
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."
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. :)