There are no inviolable truths in programming. Even the most obvious rules can have contexts in which they cannot be applied. Unfortunately, 99% of organizations have direct orders that must be followed. And there are rules that are considered rules of good tone (how not to touch the curtain). However, there are always situations when it is better to cut.

Here are some examples.

1) For example, DRY – I can’t use myself. A good useful rule, but it can be brought to madness. From what I’ve seen in practice: there are two sections with different business sense that started with simple CRUD, and many parts (both front-end and back-end) looked pretty much the same. If you combine them with the help of a common finger-sucked abstraction and thereby get rid of a small duplication of code, then (very soon) you can go crazy, because these two things will soon grow apart, overgrown with custom features, and the abstraction will only hurt. Cannot be abstracted is not abstracted even if DRY is violated.

“[Немного] duplication is much cheaper than incorrect abstraction.” —Sandy Metz

That is, DRY is a good principle, but there are exceptions.

2) KISS.

Keep it simple, stupid. Everyone would like to keep the program simple, but sometimes you have to make things more complicated in order to achieve faster development, less bugs, etc. For example, KISS can be in direct conflict with the same DRY: code with duplication is often easier to understand (fewer abstractions and dependencies), but it is a huge field for errors (forgot to fix it in the third file) and slows down the addition of new features.

3) The function should not have more than X lines, the length of the line must be no more than Y, etc. (Rules letter by letter).

Usually this X is invented from balda. In such cases, one wants to ask why exactly so much, and not one more or two less. And usually from time to time a completely valid code appears, which for some reason does not work, and people twist it as best they can, rewrite it through game in order to stretch the pipeline somehow.

4) We write only on in such a language

And dances with a tambourine begin around PHP, on which they are trying to start a highload solution. This results in the most interesting engineering tasks, how to make an airplane out of shit and sticks. Endless topics for conference presentations.

And thousands of them.

Every programmer has a neural network between his ears that he uses. It cannot be considered as a mindless robot.

If someone is stupid and constantly creates game, then maybe they should just be released? Why do you need such an employee? If this is an experienced programmer, and in most cases he acts wisely, then it may not be necessary to limit him with any nonsense – this is a decrease in efficiency, and also a decrease in motivation

I wrote about it in one Telegram channel, but I will mention it again.

What if I told you that code review is optional? Does manual testing slow down processes? Is Scrum only harmful? Is your language not suitable for your tasks? Is it harmful to measure coverage with tests?

Probably, you were triggered by at least one of these statements (for example: how can it be without a code review, and there the shitcode will flow in a river! All normal teams have it!)

Then I have a counter question: how was the decision made to introduce this into the team’s processes? I won’t speak for everyone, but I bet that in many cases it’s like this: in the last project, we did this, and when we formed a new team, we also decided to do this.

The problem is that the decision-making process was the same in the previous team. And so we see that the review code is everywhere and with everyone, and now this approach is an undeniable truth. It is almost impossible to leave it.

Or at least take Scrum — it flows from organization to organization like a virus, despite the fact that its value in many cases is questionable. The funniest thing is that most often scrum is implemented without much discussion, despite the fact that it has a very serious effect on everything. That’s just how they do it, and we will. Someone had scrum in the last project, now we will have it too. Even if it doesn’t solve any problems.

And it’s strange, because ITishniks like to say (especially on Twitter) what kind of intellectuals they are, but on key issues they often just follow the herd, rationalizing their choice as they go along at the slightest timid doubt.

A lyrical retreat about the review code, because there will surely be questions. Like any tool, a code review can be both beneficial and detrimental. In a project where human life is concerned (medical devices, autopilots of cars) or there are security issues, a code review is definitely necessary. However, in a simple product code, it is mandatory to make an approval, i.e. blocker, on every task – this is a serious deterioration of the notorious time-to-market, and perhaps in a team of professionals who have worked, this obligation will only interfere: it is enough to sometimes look at old commits for code quality control and to say in advance with words particularly complex technical solutions, but do not block everything in a row. In other words, you need a code review depends on the project and taskbut is not absolute truth.

At what point does a repeatedly repeated thought become a basic truth from which it is then impossible to deviate? I think everything is simple. This is banal laziness, saving energy. The notorious system 1 and system 2. Think how much is needed to rebuild from scrum to something else: everyone is used to story points, poker and Fibonacci, knows their role, everything is already set up in jira, all necessary retro and sprint reviews are filled in the calendar. And for transformations, you need to convince every member of the team and management. Dead number. What everyone does is the truth, and it will remain so forever. Because the system is now stable (even if not very efficient), and the transition to another stable state requires a lot of energy.

I recommend reviewing everything at least sometimes. Any processes and technologies, especially those that are annoying, should be regularly questioned.