On perfect code and harsh reality

I think no one will argue that the program code should be clean and “not smell” (code smell), and the design patterns and TDD should become faithful companions of any more or less competent developer throughout his difficult but productive career. Everyone also knows that the price of a mistake in production increases tenfold, and also that good programmers optimize the code, and bad ones buy new servers, and also that 9 women do not give birth to one child in a month .



It would be foolish to argue that writing good code is not correct. Moreover, the attentive reader will find among my past publications a series of articles on the subject of ideal code. But I decided to write this note due to the fact that recently I very often come across an idealization of the development process and a lot of tips in the style of “don't care for everything, the main thing is the ideal code”. Next, a few observations and stories from life.
')

Outsourcers profitable to write govnokod

What is there to hide - the majority of successful companies operating in local markets are outsourcers, who, as everyone knows, make money by providing services to external customers. If the fixed price is ok, there is still hope that the code will be written correctly, but if time & materials ...

Once there was such a situation: a week they did one functional, then they reworked for two days, then they returned it as it was, and then the specifications came. To my reasonable question, why it was impossible to wait for specs, and then write, I received a quite reasonable answer : did you get money for what you did and what you did, why are you not happy?

I know cases when the developers deliberately made bugs in the system in order to receive an additional order for support later. And in one of the past companies, a friend called his role in the company as a “bug maker”! He was very proud of it, because 3 developers and 2 testers did not let relax :-)

Write a good code - you can be fired!

It sounds absolutely monstrous, but you did not think. A good developer and a strong architect are always (?) A valuable employee, but in some cases (for example, in freelancing or if you are a contractor) they can get rid of you as soon as you do all the hard work and train Indian monkeys to methodically color the code in the right order. Kidding? Not.

But what about support, new developments? Everything is very simple. Very many companies live at the expense of one customer and do everything (absolutely everything) that he will say, because his departure == the end of the company. Therefore, in such a war, all means are good. Why bother with such companies? In the short term, they can be much more profitable due to the cruel deadlines, lack of resources and the vagaries of the authorities.

Refactoring for refactoring

Perhaps the problem of all good (or potentially good) developers. Throw away everything and write first! Add another syndrome "Not invented here" and get a complete set of problems ... for the authorities and the customer. After all, the developers led by team leader are not solving the business problem, but are playing a game called “ideal code”.

Sometimes you need to write govnokod

For example, if you write a prototype, test an idea, do Research & Development. In such cases, the ideal code with a three-level OOP over TDD with an AJile is more an enemy than an assistant. Since the task is to test the hypothesis, guess, save time in the future to correct architectural or functional jambs.

Why is it still considered that you need to write the perfect code?

The argument of those who say that you need to write the perfect code is built, most often, on the fact that bad code in the future is difficult to spoil. The mental error is that most often the code does not need to be supported or will not need to be supported by you. Therefore, from a business point of view, writing an ideal code is a waste of time and resources.

In one of the companies, before sitting down to write a project assessment and commercial application, I (bypassing the authorities) always asked the customer: select the desired type of assessment among the three options - “cheaper, but faster”, “work - don tach”, “do how to". Depending on the desire of the client, the budget grew 2-5 times, but then I immediately clearly understood how we would write.

The second problem is the constant dissatisfaction of the developer with his code. Monthly code I want to burn, semi-annual - to eat, because of the code written 3 years ago, I want to kill someone. Don't let Astronauts of Architecture scare you !

No need to write govnokod intentionally

Only by calculation!

In one project for a very distinguished customer at the beginning of the work there were no requirements for code conventions. Actually, not yielding to such a freebie, the team set very specific hard rules + regular review code. As a result, one week before the project was handed over, the customers expanded and rolled out code conventions, which put the authorities in a stupor (well, me too, since I needed to deliver the product). But due to the control from the very beginning of the project, all the improvements took a maximum of a day.

In general, each has its own examples and anti-examples, but I think everyone will agree that the developer, and even more professional, should be a pragmatist, and only then an architectural astronaut or a fan of perfectly clean code.

Force yourself to write at least one project “correctly”, and then you simply cannot do it differently ;-)

Thank you for your attention and snow-white code!