🥇DevOps or How We Are Losing Salary and the Future of the IT Industry

The saddest thing about today's situation is that IT is gradually becoming an industry where there is no 'stop' to the amount of responsibilities on a single person's plate.

When reading job postings, you sometimes see not 2-3 individuals, but an entire company in one persona; everyone is in a rush, technical debt is increasing, and old legacy systems look perfect against new products, simply because they at least have documentation and code comments. New products are being developed at lightning speed, but in the end, they can't be used for another year after they are written, and often that year brings no profits. Moreover, the costs of cloud services are higher than the revenue from the service. Investors' money goes into maintaining a service that isn't operational yet but has already been launched as if it were.
For 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 it works poorly and ideally shouldn't have been released in its current state. Refunds, dropping ratings, and a huge number of user bans on forums for complaints about service performance. The number of patches is not impressive; it's alarming, yet still — the product is unusable. If this approach leads to such results for a company that has been developing since '91, then the situation for companies just starting out is even worse.

But this is looking at the results of such an approach from the user's perspective; now let's consider the problems that have arisen for the employees.

I often hear the claim that there shouldn't be DevOps teams, that it's just a methodology, and so on. However, the unfortunate reality is that companies have stopped searching for DBAs, infrastructure engineers, and build engineers — now, it's just a single DevOps engineer doing everything. Of course, there are still such vacancies in certain companies, but they are becoming fewer. Many see this as progress; personally, I see it as degradation. It's impossible to maintain a high level of knowledge across all areas while working no more than 8 hours. Naturally, this is fantasy. In reality, many IT professionals are forced to work 12 to 14 hours, with only 8 being paid. Often, they work without weekends because "I was given a task, there are no docs or they are faulty, and the service costs money," and with one mistake in the cloud, you can essentially miss out on a couple of months' salary, especially if you are self-employed. We are effectively losing our say in business, along with the division of responsibilities. I increasingly encounter managers who intervene in the development processes without understanding anything about them. They confuse business data with application functionality, resulting in chaos.

When chaos begins, the business wants to find a scapegoat. Here, it's necessary to have a universal culprit, and placing blame on more than 10 people is difficult, so managers consolidate roles. The more responsibilities one specialist has, the easier it is to prove their negligence. In an Agile environment, finding a ‘culprit’ and punishing them is fundamental to this management methodology. Agile has long since moved beyond IT, and its main concept has become the requirement for daily results. The problem is that a narrowly specialized expert will not always produce daily results, making it harder to report. This is yet another reason why businesses seek “specialists in everything.” But the main reason, of course, is the payroll budget — it is the main driver of all changes. For extra pay, people were willing to work for themselves and someone else. But ultimately, just like in other fields, it has simply become a duty, for a lesser pay for an increased amount of services offered.

Nowadays, it is common to see articles suggesting that developers should also be able to deploy and handle infrastructure alongside DevOps engineers. But what does this lead to? Correctly put, a decline in service quality and a drop in developer skills. Just two days ago, I explained to a developer that writing and reading can occur from different hosts, while they insisted they had never seen such a thing. They kept mentioning settings for ORM host, port, db, user, password, and that’s it... Meanwhile, the developer knows how to trigger deployments, write YAMLs... But they forget about unit tests and comments in the code.

As a result, we observe constant overwork, seeking solutions to problems outside of working hours, ongoing learning during weekends – not for income growth but just to stay afloat. Developers are forced to assist DevOps engineers with CI/CD. When developers run out of time, they start feeling overwhelmed, and managers begin to pressure them. If that doesn't spur them into working overtime, penalties start getting enforced, and the person looks for a new job, leaving behind a technical debt as high as Everest. Consequently, this debt starts to increase among developers as well, since they are compelled to write code with less refactoring to assist either the old or new DevOps engineer, while managers are quite satisfied, as there is a clear culprit, thus the main Agile management rule is followed: the guilty party is found, and the results of their punishment are evident.

At one time, I presented a talk at ITGM titled "When Will We Learn to Say 'No'?" – the outcomes were very revealing. A vast number of people think that this word is taboo, and as long as we keep thinking this way, problems will only escalate.

Partially, this article was prompted by this article, but later I might elaborate on it in less circumlocutory terms.

Only registered users can participate in the survey. Please log in, please.