Fetish-oriented programming

During the time that I was engaged in programming, I saw quite a few projects that were bent, thanks to the fanatical following of various fashionable rules and practices. This may be something that has enticed the entire team, for example, OOP or TDD, or something that a particular developer insisted on, for example: tabs vs. spaces, or a certain style of curly braces. Even a programmer working alone can sabotage a project by choosing a fetish at the expense of productivity.
Here are some things that take hours, or even days of programmer time:

• Tabs against gaps. How much to bet?
• Brace style
• CamelCase, mixedCase, bottomreads
• Variable Naming Conventions, especially the Hungarian notation
• Functions cannot be more than 50 or 100 lines, or functions cannot be more than one screen
• Never use GOTO, eval, operator overloading, singletons, and any other language features that are considered evil.
• Functions have only one exit point.
• No global variables
• OOP only, functional programming only
• Design Patterns
• TDD (Development through testing)
• Gantt, Agile, Scrum, Extreme Programming, Custom Stories
• Never use SQL stored procedures or implement all logic on SQL stored procedures
• SQL vs. NoSQL
• Never use the short form of writing php tags
• All web interfaces must be RESTful
• HTML code must pass W3C validation
• Strict XHTML

Not all of the above is bad. And in general, for programmers in a team, it is important to follow some general rules so that their code is clear to the rest of the team members and is combined with the entire system. Problems begin when a programmer or a team decides that unquestioningly following the rules is more important than the development itself. When someone pays you, for the application, it really doesn’t matter what specific indents you use in the code. For the customer, it is important that programmers do not spend a lot of paid time, arguing about whether it is so bad to use singletons, and whether all the variable names correspond to someone’s favorite agreement.

The problem is similar to the cult of cargo in programming . It’s very bad when an inexperienced programmer does something without understanding why he does it. But even worse, when an experienced programmer turns his personal preferences into a fetish, forcing everyone who works with him to follow him, even if it means some risk for the project.
')
The last few years, I have been working a lot with the code, abandoned, after the programmer and the customer dispersed, due to cost overruns, deadlines or unwarranted expectations. I see code that doesn't even work, but comments abound with links to the Gangs of Four patterns. I see a poorly written replacement for the library, which exists only because the programmer decided that the standard title has a shame. I see specifications filled with substantiations on various technical solutions, in which there is no word about business logic.

I also often see code that does not use special indents, a certain style of curly brackets, conventions for naming variables, etc. The time I spent on bringing such a code to the form that corresponds to my aesthetic taste will be just a waste of the client’s money . I realized that code written “not to my taste” is never harder for me to read and support than my own code.

Methodologies, techniques and “best practices” should be understandable and used to solve problems, but in no way become an object of worship that must be followed at any cost. If you spend more time arguing with colleagues (or with yourself) about naming variables than writing useful code, you spend time on fetish-oriented programming.