The saddest thing in today's situation is that IT is gradually becoming an industry where there is no word “stop” at all in the number of duties per person.
When reading vacancies, sometimes you even see not 2-3 people, but a whole company in one person, everyone is in a hurry, the technical debt is growing, the old legacy looks perfect against the background of new products, because it at least has docs and comments in the code, new Products are written at the speed of light, but in the end they cannot be used for another year after they were written, and often this year does not bring profit, moreover, the costs of the "cloud" are higher than the sales of the service. Investors' money goes to the maintenance of a service that is not yet working, but which has already been released to the network as a worker.
As an example: a well-known company whose remaster of an old game received the lowest ratings in the history of the industry. I was one of those who bought this product, but even now this product works terribly, and in theory it should not have gone on sale in this form. Refunds, falling ratings, a huge number of user bans on forums for complaints about the operation of services. The number of patches is not amazing, but terrifying, but all the same - the product is not usable. If this approach leads to such results for a company that has been developing since 1991, then for companies that are just starting out, the situation is even worse.
But we looked at the results of this approach on the part of the user of the service, and now let's look at the problems that the employees have.
I often hear the statement that DevOps teams should not exist, that this is a methodology, etc., but the trouble is, companies for some reason stopped looking for knots, dba, infrastructure builders and build engineers - now it's all a DevOps engineer in a single person. Of course, some companies still have such vacancies, but there are fewer of them. Many called this development, I personally see degradation in this, it is impossible to maintain a good level of knowledge in all areas, and at the same time manage to work no more than 8 hours. Naturally, these are fantasies. In reality, many IT specialists are forced to work 12 or 14 hours, of which 8 are paid. And often seven days a week, because “I was given a task, there are no docks or curves, and even the service costs money”, and for 1 an error in the cloud can, in principle, not get a salary in a couple of months, especially if you work on an IP.In fact, we are losing our word in business, along with the separation of duties, I increasingly come across the fact that managers crawl into development processes, generally not understanding anything about them, they confuse business data and the operation of the application, as a result chaos begins.
When chaos begins, the business wants to find the culprit, and here you need a universal culprit, it is difficult to hang the guilt on 10+ people, so managers combine positions, because the more responsibilities one specialist has, the easier it is to prove his negligence. And in the conditions of Agile, finding the "culprit" and whipping is the basis of this methodology of doing business in management. Agile left IT for a long time, and its main concept became - the requirement of daily results. The problem is that a highly specialized specialist will not always have a daily result, which means it will be more difficult to report, and this is another reason why the business wants “experts in everything”. But the main reason, of course, is the payroll - it is the main reason for all the changes, for the sake of a bonus, people agreed to work for themselves and that guy. But in the end, as in other areas,it has simply become now a duty, for less payment for more of the services provided.
Now you can often see even articles about what developers should already be able to deploy, should deal with infrastructure next to a DevOps engineer, but what does this lead to? That's right - to a drop in the quality of services, to a drop in the quality of developers. Just 2 days ago, I explained to the developer that you can write and read from different hosts, and they proved to me with foaming at the mouth that they had never seen this, here they are in settings orm host, port, db, user, password and that's it .... But the developer knows how to run deployments, write yamls .... But he already forgets about unit tests and comments in the code.
As a result, we see the following - constant overwork, looking for solutions to problems outside of working hours, constant training on weekends, and not to increase income, but to keep ourselves afloat. Developers are forced to help DevOps engineer with CI / CD, and if the developer does not have time, he starts to sew up, and managers begin to punch their brains, and if this does not help increase the desire to work overtime, then apply penalties and fines, a person is looking for a new job. leaving behind a technical debt the size of Everest, as a result, the debt begins to grow among developers, because they are forced to write code with less refactoring in order to have time to help either the old or the new DevOps engineer, and the managers are quite happy with everything, because there is a guilty person and he is immediately visible, which means that the main rule in Agile management is observed, the guilty person is found,the results of his whipping are visible.
Once at ITGM I gave a report “when will we learn to say no” - its results were very revealing. A huge number of people believe that this word is taboo, and until we stop thinking that way, problems will only grow.
Part of this article was inspired by this article , but later I will probably write it down in less suave terms.
DevOps or how we are losing wages and the future of the IT industry
All Articles