Business vs Software Engineering
Somewhere I heard that in psychotherapy there is the following method of working with a patient - the patient is invited to sit down and write in a free, "streaming" form everything that boils up, excites, excites the mind and, reflecting on the subconscious, does not let you sleep at night. In relation to this, there is a good, gently caressing word - freeriting.
So, why I decided to write this - when you are faced with 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 you come across this over and over again, you already want to write about it.
The first thing you think about - maybe engineering is already dead and marketing rules the world - it doesn’t matter how it is written, designed, whether it is designed at all, the main thing is to sell, put in, vparit? And engineering as such has faded into the background, and the real "creatives" are these quick-tempered young people, sales managers, sneaky and persistent as dachshunds, getting a badger out of the hole? This thought in itself is wild sedition, but it comes to mind time after time when you observe what is happening.
Now, in detail about what is actually happening. What happens is that engineering turned out to be a servant of the business. Which is the most paradoxical, even in cases where the main selling product / service of a company is a software product. Business dictates its own rules, business limits, adjusts, business favors those people from the technical "cage" who are ready to act for it at the expense of quality and design. In this case, the management resembles a nearby person who sits on a bitch and slowly cuts this bitch, felts due to lack of knowledge, felts today profit, and tomorrow even though the grass does not grow.
However, “features of the national management” is a topic for a separate, big and rather sad conversation ...
Business in general resembles a voracious monster, which also has the ability to eat itself.
A wonderful concept is technical duty , everyone knows it, everyone read it, some even really imagine what it is. But the number of real projects that are carried out taking into account this concept in my subjective opinion is negligible.
The reason is simple - the business does not like technical debt, he hates it, even hates talking about it.
Business fell in love with scrum- but a very strange love. Scrum is in most cases just an excellent juicer. Who is in the role of fruits and vegetables? Of course, the developers. Moreover, the scrum is used as a kind of "fig leaf", covering up an untenable approach to many technical issues. Everything concerning the part “we’ll hang more functionality and make it faster” is taken from the scrum. I mean, first of all, portions of new features, the implementation of which is hung on every new sprint. But all practices regarding the quality of the code and the product as a whole, the achievement and maintenance of a change-resistant, easy-to-test and maintainable design - in most cases, are simply discarded.
Here it is necessary to make a reservation - I do not want to generalize everyone and everything, I am talking about trends that objectively exist today.
Next is 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 follows from the inferior use of scrum practice. If continuous testing is not implemented on the project exactly as one of the processes of the software life cycle — even if there are people who manually try to “click” bugs in the UI, such testing cannot be called profanation. The result - bugs that fluttered into the release due to such an attitude to QA, cause such a reputation and financial damage to the company, in comparison with which the costs of setting up a really effective process of working with product quality will seem meager.
But then again, whoever deals with these metrics, these calculations, these ratios of spent resources ... Business also does not like
documenting , spent resources are serious, the effect is not obvious, and indeed here you can also hide behind a scar: “we have a scrum, close communication with the group, we don’t need it. ”
This is despite the fact that at best 2-3 people from the group know the project thoroughly, the rest know it broadly and / or fragmentarily, as a result, if these people with “secret” knowledge leave the game, then it’s easier to rewrite everything anew, which entails costs that are not comparable with the costs 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 he starts working with a documented system from the very beginning.
And it’s good if the project has a code review, an adequately implemented modular architecture based on SOLID principles, a 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 ideal described above the situation is rather an exception to the rule ...
How to cure all these negative trends in the software development industry?
As I see it, the main pill here is education.
The faster the revered academic community matures to the realization of software engineering as a self-sufficient engineering discipline, and not the eternal “stepdaughter” of the “stepmother” -mathematics, the faster the curriculum will be adjusted, I hope more people will come from real development as teachers to universities.
The most important thing that a specialized education in the field of software development should give is a three-dimensional vision of the development process, if people have such a vision, they will probably be able to correctly place accents and close harmonize the requirements of the business with their activities.
So, why I decided to write this - when you are faced with 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 you come across this over and over again, you already want to write about it.
The first thing you think about - maybe engineering is already dead and marketing rules the world - it doesn’t matter how it is written, designed, whether it is designed at all, the main thing is to sell, put in, vparit? And engineering as such has faded into the background, and the real "creatives" are these quick-tempered young people, sales managers, sneaky and persistent as dachshunds, getting a badger out of the hole? This thought in itself is wild sedition, but it comes to mind time after time when you observe what is happening.
Now, in detail about what is actually happening. What happens is that engineering turned out to be a servant of the business. Which is the most paradoxical, even in cases where the main selling product / service of a company is a software product. Business dictates its own rules, business limits, adjusts, business favors those people from the technical "cage" who are ready to act for it at the expense of quality and design. In this case, the management resembles a nearby person who sits on a bitch and slowly cuts this bitch, felts due to lack of knowledge, felts today profit, and tomorrow even though the grass does not grow.
However, “features of the national management” is a topic for a separate, big and rather sad conversation ...
Business in general resembles a voracious monster, which also has the ability to eat itself.
A wonderful concept is technical duty , everyone knows it, everyone read it, some even really imagine what it is. But the number of real projects that are carried out taking into account this concept in my subjective opinion is negligible.
The reason is simple - the business does not like technical debt, he hates it, even hates talking about it.
Business fell in love with scrum- but a very strange love. Scrum is in most cases just an excellent juicer. Who is in the role of fruits and vegetables? Of course, the developers. Moreover, the scrum is used as a kind of "fig leaf", covering up an untenable approach to many technical issues. Everything concerning the part “we’ll hang more functionality and make it faster” is taken from the scrum. I mean, first of all, portions of new features, the implementation of which is hung on every new sprint. But all practices regarding the quality of the code and the product as a whole, the achievement and maintenance of a change-resistant, easy-to-test and maintainable design - in most cases, are simply discarded.
Here it is necessary to make a reservation - I do not want to generalize everyone and everything, I am talking about trends that objectively exist today.
Next is 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 follows from the inferior use of scrum practice. If continuous testing is not implemented on the project exactly as one of the processes of the software life cycle — even if there are people who manually try to “click” bugs in the UI, such testing cannot be called profanation. The result - bugs that fluttered into the release due to such an attitude to QA, cause such a reputation and financial damage to the company, in comparison with which the costs of setting up a really effective process of working with product quality will seem meager.
But then again, whoever deals with these metrics, these calculations, these ratios of spent resources ... Business also does not like
documenting , spent resources are serious, the effect is not obvious, and indeed here you can also hide behind a scar: “we have a scrum, close communication with the group, we don’t need it. ”
This is despite the fact that at best 2-3 people from the group know the project thoroughly, the rest know it broadly and / or fragmentarily, as a result, if these people with “secret” knowledge leave the game, then it’s easier to rewrite everything anew, which entails costs that are not comparable with the costs 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 he starts working with a documented system from the very beginning.
And it’s good if the project has a code review, an adequately implemented modular architecture based on SOLID principles, a 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 ideal described above the situation is rather an exception to the rule ...
How to cure all these negative trends in the software development industry?
As I see it, the main pill here is education.
The faster the revered academic community matures to the realization of software engineering as a self-sufficient engineering discipline, and not the eternal “stepdaughter” of the “stepmother” -mathematics, the faster the curriculum will be adjusted, I hope more people will come from real development as teachers to universities.
The most important thing that a specialized education in the field of software development should give is a three-dimensional vision of the development process, if people have such a vision, they will probably be able to correctly place accents and close harmonize the requirements of the business with their activities.