Software Development: 3. Warm and soft
In a previous note, I concluded that software development is such a unique area that talking about “similar areas” of human activity is only possible in order to simplify understanding of certain terms related to the stages of its development and management.
Strange, but the techniques that were born directly in the field of software development are not at all like those who came from outside.
')
For example, a fairly simple SCRUM, the description of which is quite possible to fit on A4 paper, but which is used by CERN. Or Agile, which can be described in the tenth paragraph which contains very general and idealistic principles according to which GitHub was made and many other cool things. Can they be used in construction? And when creating aircraft?
No, wait, what about decomposition and formalization of business processes, without which it would be impossible to automate, well, the same process of building design. But what about the planning of works, without which it would not have been possible in an organized way to create a thousand tables, logical structures and interfaces for such a project?
(as an illustration, the face of a typical universal technique of authorship RuxxSilver, which at first glance looks very attractive and believable)
While on the horizon we continue to see material production, and reproduce the interrelationships of the entities that make it up, all this is extremely important, how to see the landscape, drawing it on a sketchbook. IDEF, UML and a platoon of consultants and business analysts to help us. As soon as the landscape disappears, completely different principles come into play. Large-scale production automation projects fail, not because it’s impossible to simulate an automation object. It is difficult to miss the fact of the operation of a blast furnace or absenteeism of the department. Or do not understand how to reflect this in the model and what this entails.
They fail and fly out of the budget because they softly bucked and rejected the details of the project. Well, the system did not fit into the system of half a million parts, but everything was built on the assumption that it would fit. Writing the return logic for the written receipt suddenly, due to limitations of the original system, took not 10 man-hours but 10,000. More than 19 joins in the request to the database destroyed the entire reporting system, and the third-party module sees only three gigabytes of memory, but four are needed.
Reflecting the real world in a software product, we essentially create a chimera and its components live according to different laws, are governed according to different laws, and may begin to reject each other at an unpredictable moment. The development of a large universal database is completely different than the creation in it of a description of the connections between the details of the car. Alas, many managers confuse it more often than we would like.
Each particular organization with its specific products and approach to work solves the problem of the chimera in its own way. Very complex techniques are being created, which have one common feature - they stop working when they cross the threshold of the parent company.
Tell me, honestly, who successfully uses RUP, so that it is more than a set of general principles that fit on a piece of paper? I have a book on RUP on the shelf and a few more in electronic form. Unfortunately, it does not say who does this. The Internet also did not really help me answer this question.
Crossing the threshold of IBM, it is blown away like a ball, losing everything that distinguishes it from much more informal methods. In a formalized project that is strongly associated with the real world, it almost always starts losing methods that turn at least part of the development into a fully formalized cascade and are not tied to very specific software products, their strengths and weaknesses.
Versatility is not always good, but it always sounds good.
If we want to train a dog, we will do the same. If you want to go somewhere by car - to others. And it is not worthwhile to invent general principles for solving these two tasks just because in the first and second cases, someone controls something.
When we create a software product, we are dealing primarily with abstract entities that make it up, with external interfaces and the software and hardware environment in which it exists.
When we model the real world, we are dealing with its objects, their measurable properties and their interrelationships.
A software product may assume that it will contain a model of a certain part of the real world. The real world, in turn, can be described so that its model is easier to put into the program.
When we consider this to be identical, we begin to confuse warm and soft.
At least because of the conflict that affects the very nature of information technology. A computer and its programs are children of computing systems (especially statistical processing) and a copy machine.
For example: if we want to do the classification and management of stones, then we will have to create a class of stone or a table in the database that describes the stones.
In the least expensive form, the stones will be unified: stone No. 1, stone No. 2, stone No. 3 ... There are no identical stones in the real world. To describe all the stones you need to fully reproduce them. We can introduce into our system a multitude of stones grouped by weight, and from its point of view, the uniformity of stones will greatly decrease, it will be easier for us to determine to which group a particular stone belongs in the real world. For some tasks, information on whether this group of stones will fit into the truck can be useful. The question is how much detail will be useful and how much this benefit will be combined with costs.
The more replicable and non-specific an object is, the easier it is to process information about it. And the less work is needed to create software that processes and transforms it.
And if we want to really claim to universal methods, then most likely we need to look for their basic principles, starting from the theory of sets. Now any such attempts form such a complex apparatus that it finds only a microscopic application in the risk assessment and projects of very specific expert systems. In practice, they can be used in the form of perhaps a “naughty” black box, whose opinion is taken into account when the credibility of all other opinions is in doubt.
Summarizing: there are different goals, and according to them there are some principles: how to write good software, how to create models of the real world and how to extract economic profit from the result. If someone claims to mix these things and universal methods, then this applies to the zone of economic goals, because the “universal” sounds cool and is sold better than the “non-universal”.
Universality is also impossible in terms of applicability for various organizations and projects. The higher the degree of portability, the more the technique is similar to the compact code of vague recommendations.
The bad news is that you yourself will have to decide on goals, look for compromises, optimums, answer insidious questions like “do we need good code”. The likelihood of a beautiful waterfall process of work, as in construction, is impossible in the foreseeable future.
As market growth declines and competition inside individual subsectors increases, personal decisions of particular people with personal responsibility for them will play an increasingly important role. Software development management will not die away, but most existing IT managers with their approaches will rather die away or grow professionally. The rest will decide that the industry has become unpromising for them in terms of an easy career and money and will disappear. It is unlikely that we will lose anything from this.
And if a young IT project manager or a development team leader now seems to us to be really young people aged 15 to 30 years old, then the young architect (who designs the buildings) falls more in the age range of 30-45 years and opening the album “20 young architects” your thought will be: “And who are all these old fartors ?!”. Just because 5-7 years of training and 10 years of practice is not enough even to design a well, even Khrushchev.
In the next article I want to go down to the level below and try to test the concepts that we inherited, such as the customer and the requirements.
Strange, but the techniques that were born directly in the field of software development are not at all like those who came from outside.
')
For example, a fairly simple SCRUM, the description of which is quite possible to fit on A4 paper, but which is used by CERN. Or Agile, which can be described in the tenth paragraph which contains very general and idealistic principles according to which GitHub was made and many other cool things. Can they be used in construction? And when creating aircraft?
No, wait, what about decomposition and formalization of business processes, without which it would be impossible to automate, well, the same process of building design. But what about the planning of works, without which it would not have been possible in an organized way to create a thousand tables, logical structures and interfaces for such a project?
(as an illustration, the face of a typical universal technique of authorship RuxxSilver, which at first glance looks very attractive and believable)
While on the horizon we continue to see material production, and reproduce the interrelationships of the entities that make it up, all this is extremely important, how to see the landscape, drawing it on a sketchbook. IDEF, UML and a platoon of consultants and business analysts to help us. As soon as the landscape disappears, completely different principles come into play. Large-scale production automation projects fail, not because it’s impossible to simulate an automation object. It is difficult to miss the fact of the operation of a blast furnace or absenteeism of the department. Or do not understand how to reflect this in the model and what this entails.
They fail and fly out of the budget because they softly bucked and rejected the details of the project. Well, the system did not fit into the system of half a million parts, but everything was built on the assumption that it would fit. Writing the return logic for the written receipt suddenly, due to limitations of the original system, took not 10 man-hours but 10,000. More than 19 joins in the request to the database destroyed the entire reporting system, and the third-party module sees only three gigabytes of memory, but four are needed.
Reflecting the real world in a software product, we essentially create a chimera and its components live according to different laws, are governed according to different laws, and may begin to reject each other at an unpredictable moment. The development of a large universal database is completely different than the creation in it of a description of the connections between the details of the car. Alas, many managers confuse it more often than we would like.
Each particular organization with its specific products and approach to work solves the problem of the chimera in its own way. Very complex techniques are being created, which have one common feature - they stop working when they cross the threshold of the parent company.
Tell me, honestly, who successfully uses RUP, so that it is more than a set of general principles that fit on a piece of paper? I have a book on RUP on the shelf and a few more in electronic form. Unfortunately, it does not say who does this. The Internet also did not really help me answer this question.
Crossing the threshold of IBM, it is blown away like a ball, losing everything that distinguishes it from much more informal methods. In a formalized project that is strongly associated with the real world, it almost always starts losing methods that turn at least part of the development into a fully formalized cascade and are not tied to very specific software products, their strengths and weaknesses.
Versatility is not always good, but it always sounds good.
If we want to train a dog, we will do the same. If you want to go somewhere by car - to others. And it is not worthwhile to invent general principles for solving these two tasks just because in the first and second cases, someone controls something.
When we create a software product, we are dealing primarily with abstract entities that make it up, with external interfaces and the software and hardware environment in which it exists.
When we model the real world, we are dealing with its objects, their measurable properties and their interrelationships.
A software product may assume that it will contain a model of a certain part of the real world. The real world, in turn, can be described so that its model is easier to put into the program.
When we consider this to be identical, we begin to confuse warm and soft.
At least because of the conflict that affects the very nature of information technology. A computer and its programs are children of computing systems (especially statistical processing) and a copy machine.
For example: if we want to do the classification and management of stones, then we will have to create a class of stone or a table in the database that describes the stones.
In the least expensive form, the stones will be unified: stone No. 1, stone No. 2, stone No. 3 ... There are no identical stones in the real world. To describe all the stones you need to fully reproduce them. We can introduce into our system a multitude of stones grouped by weight, and from its point of view, the uniformity of stones will greatly decrease, it will be easier for us to determine to which group a particular stone belongs in the real world. For some tasks, information on whether this group of stones will fit into the truck can be useful. The question is how much detail will be useful and how much this benefit will be combined with costs.
The more replicable and non-specific an object is, the easier it is to process information about it. And the less work is needed to create software that processes and transforms it.
And if we want to really claim to universal methods, then most likely we need to look for their basic principles, starting from the theory of sets. Now any such attempts form such a complex apparatus that it finds only a microscopic application in the risk assessment and projects of very specific expert systems. In practice, they can be used in the form of perhaps a “naughty” black box, whose opinion is taken into account when the credibility of all other opinions is in doubt.
Summarizing: there are different goals, and according to them there are some principles: how to write good software, how to create models of the real world and how to extract economic profit from the result. If someone claims to mix these things and universal methods, then this applies to the zone of economic goals, because the “universal” sounds cool and is sold better than the “non-universal”.
Universality is also impossible in terms of applicability for various organizations and projects. The higher the degree of portability, the more the technique is similar to the compact code of vague recommendations.
The bad news is that you yourself will have to decide on goals, look for compromises, optimums, answer insidious questions like “do we need good code”. The likelihood of a beautiful waterfall process of work, as in construction, is impossible in the foreseeable future.
As market growth declines and competition inside individual subsectors increases, personal decisions of particular people with personal responsibility for them will play an increasingly important role. Software development management will not die away, but most existing IT managers with their approaches will rather die away or grow professionally. The rest will decide that the industry has become unpromising for them in terms of an easy career and money and will disappear. It is unlikely that we will lose anything from this.
And if a young IT project manager or a development team leader now seems to us to be really young people aged 15 to 30 years old, then the young architect (who designs the buildings) falls more in the age range of 30-45 years and opening the album “20 young architects” your thought will be: “And who are all these old fartors ?!”. Just because 5-7 years of training and 10 years of practice is not enough even to design a well, even Khrushchev.
In the next article I want to go down to the level below and try to test the concepts that we inherited, such as the customer and the requirements.
Source: https://habr.com/ru/post/133680/
All Articles