Business vs software engineering
Somewhere I heard that in psychotherapy there is the following method of working with a patient - the patient is offered to sit down and write in a free, “streaming” form everything that boils, excites, stirs the mind and, reflecting on the subconscious, does not allow to sleep at night. With regard to this, there is a good, gently caressing word hearing - freeriting.
So, why I decided to write it - when you face a complete disregard for software design as such, a disregard for quality and compliance with at least some development methodology, you are always surprised. When faced with this over and over again, I already want to write about it.
The first thing you think about - maybe engineering is already dead and the world is ruled by marketing - no matter how it is written, designed, is it designed at all, the main thing is to sell, lend, push? And engineering as such, has faded into the background, and the real “creatives” are these nimble young people, sales managers, sly and persistent as dachshunds, getting badger from the hole? This thought is in itself a wild sedition, but it comes to mind time after time when you observe what is happening.
')
Now in detail about what actually happens. What happens is that engineering activity turned out to be the servant of the business. What is the most paradoxical even in those cases when the main product / service of the company sold is a software product. Business dictates its own rules, business limits, drives, business favorably refers to those people from the technical "clips" who are ready to act for it at the expense of quality and design. In this case, the management resembles a close-minded person who sits on a bitch and slowly bitches this bitch, toli due to lack of knowledge, profits today, and tomorrow the grass does not grow.
However, the “peculiarities of national management” is a topic for a separate, big and rather sad conversation ...
Business generally resembles a voracious monster, which also tends to eat itself.
A wonderful concept is technical debt , everyone is familiar, everyone has read it, some even really imagine what it is. But the number of real projects that are conducted with this concept in my subjective opinion is negligible.
The reason is simple - the business doesn’t like technical debt, he hates it, even hates talking about it.
Business loved scrum - but very strange love. Scrum in most cases is just an excellent juicer. Who are the fruits and vegetables? Of course the developers. Moreover, scrum is used as a kind of “fig leaf”, covering the untenable approach to many technical issues. Everything is taken from the scram concerning the part “we will hang more functionality and we will do it quickly”. I mean, above all, portions of new features, the implementation of which is hung on every new sprint. But all practices related to the quality of the code and the product as a whole, to achieve and maintain a change-resistant, easily tested and followed design - in most cases are simply discarded.
There is a need to make a reservation - I do not want to generalize everyone and everything, I’m talking about trends that objectively exist today.
Next - QA . The concepts of quality assurance and quality control for a huge number of projects is something far and mysterious, like the Andromeda nebula. And this directly stems from the inadequate use of scram practices. If continuous testing is not implemented on the project as one of the processes of the software life cycle - even if there are people who in manual mode are trying to “snap” bugs in the UI, such testing cannot be called anything other than profanation. The result - the bugs that fluttered into the release due to such an attitude towards QA, cause such reputational and financial damage to the company, compared to which the cost of setting up a really effective process of working with product quality will seem miserable.
But again - who deals with these metrics, these calculations, these ratios of resources expended ...
The business doesn’t like documenting either, the resources expended are serious, the effect is not obvious, and in general it is also possible to hide behind the screen: “we have scrum, close communication with the group, we don’t need it”.
This is despite the fact that the project is thoroughly known at best by 2-3 people from the group, the rest know it in general and / or fragmentary, as a result, if these people with “secret” knowledge leave the game, it is easier to rewrite everything anew which entails costs incompatible with the cost of documentation. Plus, the ability to analyze the system for code refactoring or more serious reengineering. Plus, for example, the entry of a new person into the project. How much faster it will happen, how much faster a person will become effective if from the very beginning they start working with a documented system.
And it’s good if the project has a code review, an adequately implemented modular architecture based on SOLID principles, normal notation for structuring, formatting, naming variables of different levels, classes, methods - this can largely compensate for the lack of documentation, but I think the above is perfect the situation is rather an exception to the rules ...
How to treat all these negative trends in the software industry?
As I see it, the main pill here is education.
The sooner the highly respected academic community ripens to the realization of software engineering as a self-sufficient engineering discipline, rather than the eternal "stepdaughter" of the "stepmother" -mathematics, the faster the curriculum will be adjusted, I hope more people will come from the real development as teachers in universities.
The most important thing that should give specialized education in the field of software development is a three-dimensional vision of the development process, if people have such a vision, they will be able to correctly place accents with a probability close to one and harmonize business requirements with their activities as much as possible.
So, why I decided to write it - when you face a complete disregard for software design as such, a disregard for quality and compliance with at least some development methodology, you are always surprised. When faced with this over and over again, I already want to write about it.
The first thing you think about - maybe engineering is already dead and the world is ruled by marketing - no matter how it is written, designed, is it designed at all, the main thing is to sell, lend, push? And engineering as such, has faded into the background, and the real “creatives” are these nimble young people, sales managers, sly and persistent as dachshunds, getting badger from the hole? This thought is in itself a wild sedition, but it comes to mind time after time when you observe what is happening.
')
Now in detail about what actually happens. What happens is that engineering activity turned out to be the servant of the business. What is the most paradoxical even in those cases when the main product / service of the company sold is a software product. Business dictates its own rules, business limits, drives, business favorably refers to those people from the technical "clips" who are ready to act for it at the expense of quality and design. In this case, the management resembles a close-minded person who sits on a bitch and slowly bitches this bitch, toli due to lack of knowledge, profits today, and tomorrow the grass does not grow.
However, the “peculiarities of national management” is a topic for a separate, big and rather sad conversation ...
Business generally resembles a voracious monster, which also tends to eat itself.
A wonderful concept is technical debt , everyone is familiar, everyone has read it, some even really imagine what it is. But the number of real projects that are conducted with this concept in my subjective opinion is negligible.
The reason is simple - the business doesn’t like technical debt, he hates it, even hates talking about it.
Business loved scrum - but very strange love. Scrum in most cases is just an excellent juicer. Who are the fruits and vegetables? Of course the developers. Moreover, scrum is used as a kind of “fig leaf”, covering the untenable approach to many technical issues. Everything is taken from the scram concerning the part “we will hang more functionality and we will do it quickly”. I mean, above all, portions of new features, the implementation of which is hung on every new sprint. But all practices related to the quality of the code and the product as a whole, to achieve and maintain a change-resistant, easily tested and followed design - in most cases are simply discarded.
There is a need to make a reservation - I do not want to generalize everyone and everything, I’m talking about trends that objectively exist today.
Next - QA . The concepts of quality assurance and quality control for a huge number of projects is something far and mysterious, like the Andromeda nebula. And this directly stems from the inadequate use of scram practices. If continuous testing is not implemented on the project as one of the processes of the software life cycle - even if there are people who in manual mode are trying to “snap” bugs in the UI, such testing cannot be called anything other than profanation. The result - the bugs that fluttered into the release due to such an attitude towards QA, cause such reputational and financial damage to the company, compared to which the cost of setting up a really effective process of working with product quality will seem miserable.
But again - who deals with these metrics, these calculations, these ratios of resources expended ...
The business doesn’t like documenting either, the resources expended are serious, the effect is not obvious, and in general it is also possible to hide behind the screen: “we have scrum, close communication with the group, we don’t need it”.
This is despite the fact that the project is thoroughly known at best by 2-3 people from the group, the rest know it in general and / or fragmentary, as a result, if these people with “secret” knowledge leave the game, it is easier to rewrite everything anew which entails costs incompatible with the cost of documentation. Plus, the ability to analyze the system for code refactoring or more serious reengineering. Plus, for example, the entry of a new person into the project. How much faster it will happen, how much faster a person will become effective if from the very beginning they start working with a documented system.
And it’s good if the project has a code review, an adequately implemented modular architecture based on SOLID principles, normal notation for structuring, formatting, naming variables of different levels, classes, methods - this can largely compensate for the lack of documentation, but I think the above is perfect the situation is rather an exception to the rules ...
How to treat all these negative trends in the software industry?
As I see it, the main pill here is education.
The sooner the highly respected academic community ripens to the realization of software engineering as a self-sufficient engineering discipline, rather than the eternal "stepdaughter" of the "stepmother" -mathematics, the faster the curriculum will be adjusted, I hope more people will come from the real development as teachers in universities.
The most important thing that should give specialized education in the field of software development is a three-dimensional vision of the development process, if people have such a vision, they will be able to correctly place accents with a probability close to one and harmonize business requirements with their activities as much as possible.
Source: https://habr.com/ru/post/245327/
All Articles