Software Development: 1. Industry on steroids
The battle is over, people talk a lot about what method they were guided by when they made their decisions, but in general, there is always a hell of a lot of things that come to the touch.
Admiral F.D.Fletcher
A few days ago, I wondered why it happened so that a carefully worded and formalized project once again flew out of timelines and a budget with a whistle, exceeding them at times. Sometimes it happens that projects behave differently, but more often this is what happens. And it does not depend on what method I use to estimate the scope of work and the development itself. Even McConnell, whom I consider a serious authority on software development, at the beginning of Software Estimation: Demystifying the Black Art, states that simple methods for estimating project size are surprisingly no worse than complex and have the same problems. Perhaps this conclusion can be extended not only to evaluation methods.
')
In addition, like any other developer, I am somewhat worried about the prospect of the industry for the next ten years, since this is related to my professional perspectives. And, just as a person, I want to test my understanding of things for strength, to understand how local the experience and conclusions from it are.
It will be a question of fairly simple things, but I have repeatedly noticed that in scientific research progress or a dead end occurs when a simple and obvious thing turns out to be not what it seems, or a defect in a program is suddenly detected in a module that “cannot” contain an error .
(in the illustration the character of the film "Iron Man 2" Ivan Vanko at the time of pronouncing the phrase "Your software is shit")
It's hard to deny, but software has been affected by both illness and the blessing of market growth for more than thirty years now. When the market grows you do not need to be effective. When you bring mirrors and bells to the natives, they are not concerned about the quality, they do not understand them, but they want it.
Yes, there were alarming calls like the crisis of the 2000s, when the collapse of the most monstrously inefficient high-tech companies and the burning of investments in an overheated market shook the economy. It suddenly turned out that IT companies would be nice to make a profit even in the long term. The quality of products and their usefulness increased slightly, there was another influx of consumers and investments. And this thought again faded into the background.
If I work as a technologist or methodologist in the production of mirrors and bells for Papuans, then for me it makes no sense to be effective. The growth factor will confirm almost any of my decisions as correct, and a good sales policy will completely ignore the fact that the product itself is a problem. Mirrors can be split, almost nothing to reflect and not ring, but they will be sold, they will go especially well for those who have not seen other mirrors and if the factor “I want like him” began to act. It is not only individuals who are subject to it. We want to modernize, because everyone is introducing ERP or CRM, or opening up an Internet direction only because everyone does it. For some reason, this behavior does not seem surprising to me.
During this time, a large number of software development and evaluation methodologies emerged.
In theory, thanks to them, order arises out of chaos, the whole product is beautifully decomposed into characteristics, functionality, architectural features, etc. And the creation is divided into quite a finite number of processes that are subject to unification and measurement. Cool, beautiful, and it looks like an exact science.
I have two thermometers, one old mercury, the other a new electronic one. I want to know the temperature of my body in order to see if I am getting sick. I take an old thermometer and after 5 minutes he shows me with his mercury column something like 37.2 degrees. Then I take a new, beautiful and safe thermometer, press a button, it picks and after a minute shows me 36.638 degrees. Which thermometer will you send to the dump?
Most will send the old one, because it is slow, it looks impure, and you can get fewer digits after the comma, which has nothing to do with the measurement accuracy and, accordingly, I’ll get the prediction. And in the end it cost more money, throwing a pity.
Such accuracy is only an illusion oriented towards increasing trust. Software development and evaluation methods want to look scientific, because it makes them more solid and it can be sold more expensive. The time of the specialist who uses them also starts to be valued more expensive.
Yes, it gives an understanding of how to increase budgets and the volume of jobs, but how does this relate to the stated goals of any methodology, namely: Reducing the amount and cost of the work required to create a specific software product or change an existing one to a certain state.
What is the “state of the product” is a separate issue and I would prefer not to touch it for the time being, as it concerns primarily the requirements and measurement methods for which there are many questions.
There are many goals, and this wording with at least a small extension will somehow seem contradictory for the customer, developer, or manager located between them.
If I am a developer, I want from the method of help to do my job as best I can. As little as possible to repeat the code. As rarely as possible to let the whole modules under the knife and correspondence from scratch. Be sure that a certain part of the code will work correctly under most conditions. Quickly look for defects. Quickly connect to the development process of a new employee.
From a business point of view, another thing is important - making a profit from the difference in the cost of work and the project budget. Predictable process and costs. Legal streamlining of product requirements. Binding to the stages of financing and calendar periods. Formation of customer dependency on product support and release of new versions.
Each of the lists can be continued at will. But these are two different planets, in some places the goals coincide, often contradict each other, often in different dimensions. Adapt the method of testing the product to quarterly periods ?! And this, in general, how?
Sometimes it comes down to finding a compromise. I want to have a quality code without defects, but I want to submit the project within the specified period. None of the methods will resolve this contradiction, the optimum depends on the specific case. Probably it will not be possible to hand over a product containing critical defects, no matter what the deadline. And it will not be possible to spend half a dozen years for the mathematical justification of the correctness of the code. (although, strangely enough, it happens this way and that ). Or, as noted by one good specialist, the general problem of the existence of a computer is the simplification of repetitive and routine operations. From a business point of view, if they bring him profit, they are profitable.
The main problem is that by pretending to cover as many goals as possible, all existing methods have passed an extremely gentle test of effectiveness. Does our software work and sell? Then we were able to assemble a new version and also sell it somehow? Probably, we have excellent methods, since we are capable of such significant achievements.
I open the browser and it is assumed that there are a large number of companies that have shaped the face of what I see in it. Nope, in fact, this person forms the fact that a hundred people opened the browser for the first time while you were reading this paragraph, the rest is for the details.
Gradually and unevenly for different areas, but the software market will become closer to saturation and will begin to tear where it is thin. Systematic failures of certain types of projects are likely to lead to failure and a change in whole paradigms. Probably the largest of them relate to ideas about the industry and project management within it.
In the following notes, I want to consider where the techniques and management features came from and find out what is wrong with them.
Software Development: 2. Legacy
Software Development: 3. Warm and soft
Admiral F.D.Fletcher
A few days ago, I wondered why it happened so that a carefully worded and formalized project once again flew out of timelines and a budget with a whistle, exceeding them at times. Sometimes it happens that projects behave differently, but more often this is what happens. And it does not depend on what method I use to estimate the scope of work and the development itself. Even McConnell, whom I consider a serious authority on software development, at the beginning of Software Estimation: Demystifying the Black Art, states that simple methods for estimating project size are surprisingly no worse than complex and have the same problems. Perhaps this conclusion can be extended not only to evaluation methods.
')
In addition, like any other developer, I am somewhat worried about the prospect of the industry for the next ten years, since this is related to my professional perspectives. And, just as a person, I want to test my understanding of things for strength, to understand how local the experience and conclusions from it are.
It will be a question of fairly simple things, but I have repeatedly noticed that in scientific research progress or a dead end occurs when a simple and obvious thing turns out to be not what it seems, or a defect in a program is suddenly detected in a module that “cannot” contain an error .
(in the illustration the character of the film "Iron Man 2" Ivan Vanko at the time of pronouncing the phrase "Your software is shit")
1. Industry on steroids
It's hard to deny, but software has been affected by both illness and the blessing of market growth for more than thirty years now. When the market grows you do not need to be effective. When you bring mirrors and bells to the natives, they are not concerned about the quality, they do not understand them, but they want it.
Yes, there were alarming calls like the crisis of the 2000s, when the collapse of the most monstrously inefficient high-tech companies and the burning of investments in an overheated market shook the economy. It suddenly turned out that IT companies would be nice to make a profit even in the long term. The quality of products and their usefulness increased slightly, there was another influx of consumers and investments. And this thought again faded into the background.
If I work as a technologist or methodologist in the production of mirrors and bells for Papuans, then for me it makes no sense to be effective. The growth factor will confirm almost any of my decisions as correct, and a good sales policy will completely ignore the fact that the product itself is a problem. Mirrors can be split, almost nothing to reflect and not ring, but they will be sold, they will go especially well for those who have not seen other mirrors and if the factor “I want like him” began to act. It is not only individuals who are subject to it. We want to modernize, because everyone is introducing ERP or CRM, or opening up an Internet direction only because everyone does it. For some reason, this behavior does not seem surprising to me.
During this time, a large number of software development and evaluation methodologies emerged.
In theory, thanks to them, order arises out of chaos, the whole product is beautifully decomposed into characteristics, functionality, architectural features, etc. And the creation is divided into quite a finite number of processes that are subject to unification and measurement. Cool, beautiful, and it looks like an exact science.
I have two thermometers, one old mercury, the other a new electronic one. I want to know the temperature of my body in order to see if I am getting sick. I take an old thermometer and after 5 minutes he shows me with his mercury column something like 37.2 degrees. Then I take a new, beautiful and safe thermometer, press a button, it picks and after a minute shows me 36.638 degrees. Which thermometer will you send to the dump?
Most will send the old one, because it is slow, it looks impure, and you can get fewer digits after the comma, which has nothing to do with the measurement accuracy and, accordingly, I’ll get the prediction. And in the end it cost more money, throwing a pity.
Such accuracy is only an illusion oriented towards increasing trust. Software development and evaluation methods want to look scientific, because it makes them more solid and it can be sold more expensive. The time of the specialist who uses them also starts to be valued more expensive.
Yes, it gives an understanding of how to increase budgets and the volume of jobs, but how does this relate to the stated goals of any methodology, namely: Reducing the amount and cost of the work required to create a specific software product or change an existing one to a certain state.
What is the “state of the product” is a separate issue and I would prefer not to touch it for the time being, as it concerns primarily the requirements and measurement methods for which there are many questions.
There are many goals, and this wording with at least a small extension will somehow seem contradictory for the customer, developer, or manager located between them.
If I am a developer, I want from the method of help to do my job as best I can. As little as possible to repeat the code. As rarely as possible to let the whole modules under the knife and correspondence from scratch. Be sure that a certain part of the code will work correctly under most conditions. Quickly look for defects. Quickly connect to the development process of a new employee.
From a business point of view, another thing is important - making a profit from the difference in the cost of work and the project budget. Predictable process and costs. Legal streamlining of product requirements. Binding to the stages of financing and calendar periods. Formation of customer dependency on product support and release of new versions.
Each of the lists can be continued at will. But these are two different planets, in some places the goals coincide, often contradict each other, often in different dimensions. Adapt the method of testing the product to quarterly periods ?! And this, in general, how?
Sometimes it comes down to finding a compromise. I want to have a quality code without defects, but I want to submit the project within the specified period. None of the methods will resolve this contradiction, the optimum depends on the specific case. Probably it will not be possible to hand over a product containing critical defects, no matter what the deadline. And it will not be possible to spend half a dozen years for the mathematical justification of the correctness of the code. (although, strangely enough, it happens this way and that ). Or, as noted by one good specialist, the general problem of the existence of a computer is the simplification of repetitive and routine operations. From a business point of view, if they bring him profit, they are profitable.
The main problem is that by pretending to cover as many goals as possible, all existing methods have passed an extremely gentle test of effectiveness. Does our software work and sell? Then we were able to assemble a new version and also sell it somehow? Probably, we have excellent methods, since we are capable of such significant achievements.
I open the browser and it is assumed that there are a large number of companies that have shaped the face of what I see in it. Nope, in fact, this person forms the fact that a hundred people opened the browser for the first time while you were reading this paragraph, the rest is for the details.
Gradually and unevenly for different areas, but the software market will become closer to saturation and will begin to tear where it is thin. Systematic failures of certain types of projects are likely to lead to failure and a change in whole paradigms. Probably the largest of them relate to ideas about the industry and project management within it.
In the following notes, I want to consider where the techniques and management features came from and find out what is wrong with them.
Software Development: 2. Legacy
Software Development: 3. Warm and soft
Source: https://habr.com/ru/post/133676/
All Articles