SOLID is a lie

You have probably heard a lot of times that programmers have common wisdom that says you need to write SOLID code, use TDD, Dependency Injection… Basically by that they mean that you need more abstraction. But abstractions makes code more complex. When code is complex it is much easier to introduce bugs. What I strive for:

If you look at the code on the left part of top image, it’s author assumes that you will need to change count of lines. But exercise probably didn’t mentioned that. The same happens at work. You have one task, but you assume that in the future there will be a need to change some things and you make your code harder.

This code is from real project where users can make orders. Website admin can configure some variables how price is calculated. But this price is hardcoded, because I didn’t thought that it will be changed often. By hardcoding it I didn’t had to make a page for admin to edit it. If in the future price will need to change it will be easy to change it just in one method. And if admin will need to change it often, then I will make a page for that. So by not making assumptions about the change I am saving time.

Of-course sometimes you know in advance that some things will need to change, then it will be foolish not to make that part changeable.

If you listen for his talks, they are certainly entertaining, but will you get some knowledge? Nope. It is like cereal for breakfast, a lot of carbs but you still feel hungry after few hours. What I mean is that his principles are like hype words, loud, but almost no value. For example “single responsibility principle” says that a class should have only a single responsibility. I will paraphrase that, it says that programmer must decide what belongs in one class. Really? The rule says that I must decide? It’s like we don’t know that only we can decide were to put our code.

Don’t get me wrong, sometimes we need abstraction. But sometimes doesn’t mean all the time.

Also when listening for someone advice I am usually trying to understand how much that person knows. For programmers the easiest thing is to check their GitHub account to see if they apply their principles in practice. Go check Uncle Bob’s GitHub. He is programming over 40 years.

Usually guys like cars and sometimes we need to unscrew a bolt. What do you use for that?

As you see there a several tools that can unscrew bolts. Some of them are more universal and some a better at their job. I bet half of you don’t know that the red tool is a torque wrench that beeps when you reach certain torque.

Have you ever used your foot to screw or unscrew bolts. Do you know that all car manufacturers specify torque for tire bolts? Ideally you should use torque wrench for everything. But in real life we use what is easier. Of-course there is a very small chance that you will break the bolt, but somehow cars don’t have torque wrenches in their boots for tire changes.

But why programmers got the idea that everything must be done perfectly?

My recommendation would be — write code as simple as possible. You will always be able to make it harder.

Related posts:

Whenever we hear the word trust, what comes to mind is a virtue meant for some religious or a social value to cement loyalty in relationships. It is rarely connected to the world of business. But how…

Para instigar novas ideias, Neil Gaiman aconselha que você pense “E se…”. E se gatos conversassem comigo? E se debaixo daquela ponte morasse um duende furioso? E se as árvores acordassem e…

ruangan dengan dominasi warna putih berlatar belakang kaca yang mengarah langsung pada padatnya kota tak pernah diisi dengan suasana seaneh ini. lugas dewangga masih tetap mempertahankan gestur…