The effect of the second system
When a team’s technical debt slowly begins to exceed all conceivable and inconceivable boundaries, the team will have at least two ways to pay it off: refactor the system so that the cost of future changes is not so high or leave the current version of the system alone and rewrite everything anew. In the first case, it is easy to face the refactoring syndrome , when changes are not made with the intention of reducing the cost of future changes, but are made just for the sake of changes. In the second case, the “second system effect” may occur, when unnecessary functions of the system are developed and improved, and the idea “but not rewrite everything is nafig” is the first and only one that occurs to the team as soon as it encounters someone else's code
And although in the classical sense, the “effect of the second system” is slightly different from the pathological dislike for someone else’s code and its constant rewriting, both of these cases have something in common, so it makes sense to consider both these symptoms together.
If you look carefully around, you can see a remarkable manifestation of the effect of the second system in ... parenting. Grandmothers and grandfathers often relate to raising their grandchildren in a completely different way than they did to raising their own children. And the parents themselves very often try to correct their own problems, instilling in children a love for what is interesting to them, trying for the children to achieve their unfulfilled goals.
')
Since many developers and architects are also investing their soul in creating software systems, it is not at all surprising that by starting a new version of their offspring, they are trying to correct all errors and shortcomings, and are trying to create an ideal system. In addition, inspired by the success of the first system (in case of failure everything is simple, the second version of the system simply does not work), the developers begin to think that they have enough knowledge and experience in this subject area to draw general conclusions based on the existing private knowledge. This often leads to a premature generalization of the solution, which is often considered to be no less evil than the premature optimization (*).
Another problem in creating a second system is the incorrect revaluation of values, when the obsolete functions of the system are brought to perfection, and fundamentally new approaches and solutions are not developed. This leads to a terrific implementation of functions not needed by anyone, which may be useful from a purely aesthetic point of view, but it is hardly useful for the success of the system.
All these problems are described by Frederick Brooks in his “Mythical Man-Month”, where, in addition to describing this problem, recommendations are given on how to solve it. And although it was published long before Andy Hunt and Dave Thomas's other great book, The Programmer-Pragmatist, Brooks gives the same advice as is constantly heard in the book of pragmatists: no need for extremes, and more pragmatism and self-discipline.
Agree that we know with you why the development of the previous system, which the neighboring team did, failed. If I managed its development (I’d like its architect / lead / developer to emphasize the right option), I’d do everything differently, and we wouldn’t break the deadlines for half a year, and there would be 4 times less glitches.
However, the problem is that most people with some arrogance look at the failures of other people, short-sightedly believing that they would have done better. 87.5 percent of programmers believe that they would have done this job better, and only 2.5 percent (**) of them would actually do it better. The rest simply would have done it "in their own way", though with the same success in terms of terms, quality and functionality.
In addition to programmers, managers and customers suffer from such garbage. How many times have you encountered a situation when you were “offered” to rewrite the system, simply because no one understands the current version? Moreover, it was proposed to get the demands independently from the code of the same system through which the herd of Hindus passed. So to understand what the hell is happening there is already very difficult, and what should be the result is also clear, as the theory of relativity for a ten-year-old child.
As a result, the quality of the new system is determined by the weakest link in the entire development chain, and in the absence of requirements, it cannot be high at all. So the same eggs are obtained, but the side view, though for a while the new system becomes more “expandable”, because it is so far understood by the pair of fighters who declassified the existing logic in the process of its transfer to the new system.
If the syndrome of the second system, if desired, can be overcome, or at least significantly reduce the risk of clinical cases, then coping with the problem of rewriting is somewhat more difficult. If the tendency to rewrite lies in the soul of a programmer or architect, then you need to deal with it in a similar way. Indeed, there are cases when it is not just possible, but it is exactly necessary to burn the bridges and start everything from a clean slate, but in most cases such attempts should be treated in the same way with pragmatism and caution.
If this is a requirement of the manager or even the customer, then in this case, most likely the alternatives simply will not remain: you will have to rewrite; you just have to try not to exchange the awl for soap and try to take into account the main mistakes of the previous system as much as possible.
--------------------------------------
(*) In some way, a premature generalization can be considered as a premature optimization of architectural solutions. The only difference is that when it comes to premature optimization, it concerns unnecessary waste of labor resources aimed at an unnecessary increase in application performance. And when it comes to a premature generalization, it concerns a similar waste of time and effort, but for an unnecessary generalization of the solution.
(**) It is scientifically proven that 78.5% of statistics are taken from the ceiling :)
And although in the classical sense, the “effect of the second system” is slightly different from the pathological dislike for someone else’s code and its constant rewriting, both of these cases have something in common, so it makes sense to consider both these symptoms together.
The classic effect of the second system
If you look carefully around, you can see a remarkable manifestation of the effect of the second system in ... parenting. Grandmothers and grandfathers often relate to raising their grandchildren in a completely different way than they did to raising their own children. And the parents themselves very often try to correct their own problems, instilling in children a love for what is interesting to them, trying for the children to achieve their unfulfilled goals.
')
Since many developers and architects are also investing their soul in creating software systems, it is not at all surprising that by starting a new version of their offspring, they are trying to correct all errors and shortcomings, and are trying to create an ideal system. In addition, inspired by the success of the first system (in case of failure everything is simple, the second version of the system simply does not work), the developers begin to think that they have enough knowledge and experience in this subject area to draw general conclusions based on the existing private knowledge. This often leads to a premature generalization of the solution, which is often considered to be no less evil than the premature optimization (*).
Another problem in creating a second system is the incorrect revaluation of values, when the obsolete functions of the system are brought to perfection, and fundamentally new approaches and solutions are not developed. This leads to a terrific implementation of functions not needed by anyone, which may be useful from a purely aesthetic point of view, but it is hardly useful for the success of the system.
All these problems are described by Frederick Brooks in his “Mythical Man-Month”, where, in addition to describing this problem, recommendations are given on how to solve it. And although it was published long before Andy Hunt and Dave Thomas's other great book, The Programmer-Pragmatist, Brooks gives the same advice as is constantly heard in the book of pragmatists: no need for extremes, and more pragmatism and self-discipline.
Syndrome "And not to rewrite all nafig"
Agree that we know with you why the development of the previous system, which the neighboring team did, failed. If I managed its development (I’d like its architect / lead / developer to emphasize the right option), I’d do everything differently, and we wouldn’t break the deadlines for half a year, and there would be 4 times less glitches.
However, the problem is that most people with some arrogance look at the failures of other people, short-sightedly believing that they would have done better. 87.5 percent of programmers believe that they would have done this job better, and only 2.5 percent (**) of them would actually do it better. The rest simply would have done it "in their own way", though with the same success in terms of terms, quality and functionality.
In addition to programmers, managers and customers suffer from such garbage. How many times have you encountered a situation when you were “offered” to rewrite the system, simply because no one understands the current version? Moreover, it was proposed to get the demands independently from the code of the same system through which the herd of Hindus passed. So to understand what the hell is happening there is already very difficult, and what should be the result is also clear, as the theory of relativity for a ten-year-old child.
As a result, the quality of the new system is determined by the weakest link in the entire development chain, and in the absence of requirements, it cannot be high at all. So the same eggs are obtained, but the side view, though for a while the new system becomes more “expandable”, because it is so far understood by the pair of fighters who declassified the existing logic in the process of its transfer to the new system.
If the syndrome of the second system, if desired, can be overcome, or at least significantly reduce the risk of clinical cases, then coping with the problem of rewriting is somewhat more difficult. If the tendency to rewrite lies in the soul of a programmer or architect, then you need to deal with it in a similar way. Indeed, there are cases when it is not just possible, but it is exactly necessary to burn the bridges and start everything from a clean slate, but in most cases such attempts should be treated in the same way with pragmatism and caution.
If this is a requirement of the manager or even the customer, then in this case, most likely the alternatives simply will not remain: you will have to rewrite; you just have to try not to exchange the awl for soap and try to take into account the main mistakes of the previous system as much as possible.
--------------------------------------
(*) In some way, a premature generalization can be considered as a premature optimization of architectural solutions. The only difference is that when it comes to premature optimization, it concerns unnecessary waste of labor resources aimed at an unnecessary increase in application performance. And when it comes to a premature generalization, it concerns a similar waste of time and effort, but for an unnecessary generalization of the solution.
(**) It is scientifically proven that 78.5% of statistics are taken from the ceiling :)
Source: https://habr.com/ru/post/121213/
All Articles