The problem of not understanding the existing code, or what the management should not do
It happens that a hierarchy is built in a product IT company, in which the upper levels of the company’s employees do not understand at all how the product that the company produces and sells is made. In reality, managers know how to sell, but they don’t know how to make. For production, which is logical, performers with experience are hired. This is normal practice. But further, depending on how the processes within the company are built, there may be problems. I would like to write about some problems in this article.
I don’t have experience in companies where upper level managers trust lower level performers. Maybe there was trust, but I didn’t notice it. From my side, all the actions of the management looked as if they were not interested in the opinion of people who have experience in a specific field and work directly with specific areas in the company for which they were actually hired. My experience now is based only on companies where management reserves all key product decisions. Which definitely has a negative effect on the product, since the outcome of the decision-making process is highly dependent on the experience of the management. That is, if the management knows only how to sell, it will make decisions in this direction.
This article is essentially a logical continuation of the previous article “The problem of understanding existing code, or How to do sometimes [не] need”. At first, I wanted to expand on the previous article, because I saw that some theses in it were revealed by me too little or too one-sidedly. And while I was preparing to revise the article at my current place of work, an event occurred that made me a little mad. In the previous article I emphasized that programmers should know the code used in the company, but in one place I made a remark:
Understanding the codebase a programmer is working with is the Base. Every programmer in the company should have this understanding. In fact, not only programmers should have such an understanding, but this thesis is not yet within the scope of this article.
This will be discussed further.
Manual and code
At the current place of work, the simplified hierarchy of the company is built as follows. There is a director, the head of the entire company, who makes all decisions about products himself. Under the director is a group of heads, managers of individual products, each of them is responsible for his product, that is, he invents a development path, outlines the “TOR”, passes it on to the team leaders. Under the heads – separate teams engaged in separate areas of activity: designers, programmers, testers. Each team has its own ice, the head of the department, if it’s simpler, and a number of employees (large, smaller, and even a small plate…) And if you summarize it in the form of a picture, it will look approximately like a triangle.
For understanding. There could be many more workers in the teams, I was just too lazy to share.
And in the current company where I am currently working, there is a feature that clearly divides the hierarchy into two large parts – this is the understanding of how the product code works. Visually, it will look like a refined Masonic pyramid.
That is, in my opinion (not only mine, actually, but in the article I will write for myself), neither the director nor the heads understand how the code used to create products works. This creates a huge gulf of discommunication. Ordinary line personnel sometimes do not understand at all in which direction the company is moving. It is clear that any business strives to increase profits. But how this is achieved, what skills should be developed in the future, etc., is sometimes not clear at all.
There are very funny situations when heads set the task of making an MVP for entering a new market. And a certain exit date is set. And they answer that it will not be possible to do in this period. It is necessary to conduct an analysis of opportunities, availability of resources, and then start implementation. That setting hard deadlines for MVP is pointless, because the current code is full of technical debt, and there is no simple way to add the configuration of a new store or library to support a new distribution platform. The heads swear a lot at this, remarking that there are already other stores and distribution platforms, and they, the heads, see no problem in adding new ones.
And on this misunderstanding sometimes quite serious conflicts are built, which reach the director. And the director, having the habit of making decisions on his own, not having the desire to understand the problem of the code, issues a decision to be made in time, based on information from the heads that in this period there will be maximum profit, or the maximum influx of new users, or a competitor may leave earlier. That is, a decision is made without taking into account problems in development. Perhaps the risks were laid in time, but I repeat, the director and heads do not understand the code. They may understand that the risks considered may be calculated incorrectly.
Why is there no understanding?
As it seems to me, because, first of all, programming is difficult. For this, in fact, people who understand the code and work with it are hired. Secondly, there is no desire to take responsibility in a field in which a person understands nothing, or understands very little. A hypothetical example, today the director or head agreed to an innovation, and tomorrow everything broke because of this innovation. This leads to loss of profit etc. The example is hypothetical, but there are suspicions that someone was shot, because it is actually an example from experience. This was the excuse of one of the lower level bosses at one of the previous places of work.
Often management takes a step towards the development teams and asks them to explain in simple terms the essence of the problems so that solutions can be found. But the requirement to explain in simple terms often boils down to a situation where the analogies and examples that make the problem clear are so simple, or in management’s personal understanding, simple that management doesn’t see the complexities and is surprised that the development team can’t solve the problem. And in fact, the problem that appears in simple analogies affects the entire code. All development teams will be involved in supporting the changes, which will take time away from their tasks. The implementation period will vary by months. That is, the management should take responsibility for increasing the deadlines of all works, but it did not go for it, because for him the problem did not seem difficult and requires revision of the deadlines of all teams. There were such examples in my practice. That is, the abstractions that managers sometimes like do not reflect the essence, because the manager can understand something else by abstraction, not what I actually mean. And sometimes the situation can reach absurdity, which is better described with a picture.
And the most annoying thing for me is that there are situations when management notices that if someone, such as me, could not explain the problem to the manager, then I do not understand this problem myself. This is a very convenient position for a manager. In it, he abdicated responsibility and put a subordinate in his place. But in fact, there are two subjects here, they both participate in the dialogue. It turns out that there is no dialogue. And if there is no dialogue, where will the understanding of the one who does not understand come from.
I’ve had a manager come into a meeting showing interest in solving problems in the code, but by presenting and explaining solutions. This can often be found in the form of the expression “criticize – suggest”. And it seems logical. But here it often happens that solutions require to be described from the point of view of benefits for the company. And this means that it is necessary to move to the level of understanding of the manager, which again means that he will still not have an understanding of the problem. Because in fact the problem itself is not at his level. The problem is in the code. Not his. He can’t get along with her. Which again is logical. And seemingly any problem in the code can be turned into profit. But it happens that the profit will be visible only at a very long distance, or the profit can be so small in relation to the overall profit of the company that, according to the logic of finance, it does not make sense to spend the time of the teams on solving the problem. That is, even a situation where development teams spend a lot of time bypassing technical debt in the code can be quite convenient for the management, since the profit is coming, the deadlines for completing the tasks are met. Why would the management change anything? Recognized? Do you agree?
Why is this happening?
In the case of the company where I work, there are no high-level technical specialists among the heads. There are a few people who have experience in IT but not in development. And that is why they do not know the specifics of the development itself or overestimate themselves. And for some reason, the director does not want to hire, or put a specialist at his level from the current employees in the role of a consultant. Here I am personally at a loss as to why.
Not infrequently it happens, as was described earlier, that everything suits everyone. This is how business processes in the company are built. Whether this is good or bad depends on the level of the company at which the person responsible for this issue is located. From my side, this is bad. Because there are code problems that resulted in a whole article “The problem of understanding the existing code, or How to do sometimes [не] need”. Difficult to understand the code. Hard to maintain. Many things make it more difficult to work with the code. And this directly affects the deadlines for completing tasks, the specialist’s well-being, when he realizes that he needs to get into the “spaghetti” again and add something else to it, which will only aggravate the situation, and there are no other options.
The desire to release the product as soon as possible, due to which “red flags” and warnings of experts are ignored. All grievances are rejected by the willful decision of the management. Something like, you don’t want to work – go outside, no one is detained. Almost quotes. This leads to the fact that at the start of the project the team receives a disgusting, knee-jerk code, which continues to be maintained, so it brings the arrival. And the problems are not solved, because the management did not demand to do badly, the developers did badly, there is no responsibility on the management. After all, in reality, the management is just as responsible, because it made the decision. The expression “Tyap, lyap and in the production” did not appear on the same place. It’s good when refactoring happens after all. But this, judging by some articles and comments on the Internet, in particular on Habra, is a rare phenomenon. Usually, the problem code is rewritten after a year. It also happens that the engineer’s rule works – “It works – don’t touch it.”
Instead of output
How to avoid it. This is what the title of this part was supposed to look like, but I don’t really know how to avoid it. My advice will be something like “do good and don’t do bad”. Which is not productive. I only outlined the problems with the article. I will leave the conclusions to you. Running a business is hard, maybe as hard as programming. And problems at the developer level don’t always seem so important when there are more important problems at the management level. On the other hand, the company should have a dialogue. Not the visibility of it. There must be trust. Especially when someone does not understand the other’s area of competence. Because it is very bad when there is no trust. This leads to situations from experience when the development team is engaged in a large project that will allow adding new functionality to the code, which can be used in the future to obtain more profit. But the management refuses to accept the project due to mistrust and demands to return everything to the back.
That’s all. Thank you