Why I don't like DevOps (and modern software)

Foreword

This article is very subjective and based on my experience in the IT industry (I am a developer with 10 years of experience and experience in various projects, teams and countries (Kazakhstan, Canada)). I am sure that many will not support my point of view and may call this article “weep dinosaur”, but I still want to share it ...

What is DevOps?

According to Wikipedia, DevOps is a set of practices aimed at the active interaction of development specialists with information technology service specialists and the mutual integration of their work processes into each other. Those. This is an attempt to scale Agile the entire software development process, including implementation and maintenance. The main purpose of DevOps is to increase the frequency of releases and increase the responsibility of the team for the product. It sounds perfect ... like any marketing slogan ...

From my point of view, the main task of DevOps is to reduce costs for a business (which is good, but often it comes at the expense of the quality of the product).

How DevOps Kills Quality

If you go back to the 90s and 00s, then to create a product, you needed several roles in the team: analyst, project manager, developer and tester, and implementer. Each of these roles is important for creating a quality product: the analyst collects requirements and protects developers from unnecessary interaction with the customer / users, the manager coordinates the team’s work and solves organizational and financial issues, the developer writes the code and corrects the bugs, the tester finds these bugs and verifies the compliance requirements, implementer - installs software and is the first line of user support, protecting developers from unnecessary questions. Although this system is slightly cumbersome, it has a clear division of roles in the team and the new functionality passes through several people, which improves the quality and allows you to look at the problem from several points of view, which results in a good and stable result.
')
In the 2000s, this approach was replaced by Agile, which on the one hand more involved customers in the development, on the other hand, greatly reduced or cut out the role of analysts and project managers. At the same time, implementation remained isolated from the main part of the team. Gradually, the expanded productions began to be replaced with features in the backlog. As a developer, I still love Agile more than I do not. He improved the quality of interaction between team members and involved the customer in the process. The main disadvantage of this approach was the loss of the vision of the project as a whole. Those. The concept of a whole product was replaced with a set of features, which led to the first failure in quality. The development began to be a patchwork, when a new feature was nailed to an existing one and, as a result, the system lost its integrity (although this problem does not exist in teams with good architects / analysts, because control avoids such problems).

Now Agile turns into DevOps. Under the slogan of increasing responsibility for the product, testing is almost completely cut out from the teams, and the implementation is significantly curtailed and turned into a part of the development. The developer’s role is increasing, but in fact only they remain in the team, and the testing itself partially goes into automation, partially falls on the shoulders of beta testers and customers. Now many companies (especially in the West, where the cost of labor is much higher) proudly declare that their teams have no testers, and the developers own the product and are responsible for its quality. But what's the problem?

Initially, the product went through several stages of quality control: first, the analyst filtered customer requirements and thought through the implementation, then the developer checked the formulation and interacted with the analyst to improve it. Further, in the course of implementation, ideas for improvement were born and they were added to the work. Then the tester checked the product and corrected the errors. Further, the analyst demonstrated the work to the customer and the comments were eliminated.

Now there is only a feature in backlog, developed functionality and auto-tests and acceptance by the customer (if any). In fact, only one person owns the feature and there is no longer that level of interaction in the team.

DevOps problem in developers. They are not able to qualitatively analyze the requirements and test the result, because they look at the product through the prism of the code, and not from the point of view of users. Therefore, the quality of software products has recently dropped dramatically and they have become less user-friendly (take for example the latest version of Skype, although there are much more examples ...).

Is there a solution?

From my point of view, there is a solution, and it is quite simple. We need to preserve the roles of analysts, testers and implementation in the team. The division of labor leads to an increase in quality and productivity (remember Stakhanov and his idea of ​​the division of labor in the mine). Moreover, all this is easy to integrate into the DevOps process. Here is my idea: analysts collect customer and customer requirements and are product owners for developers, the role of tester and developer is clear, implementation either merges with analysts, or interacts closely with it (thereby closing the DevOps loop). From DevOps there is a high degree of automation of testing and implementation, the constant availability of a stable version of the product and the frequency of releases (or rather, I would say that each build is a release in this case). Another important rule is to be customer-oriented and customer-centric. Those. customer needs should be paramount. It is not strange that both of these principles have been successfully used for many years in such outsourcing companies as EPAM (hello to former colleagues!) And have proven themselves well there. True, automation was not so well developed before, but I hope they have already filled this gap ...