Is it difficult to develop software?
Sometime the other day I talked with a friend about what the development process is, do programmers work or crush bugs? Can anyone become a developer? What is the complexity of the software development process? I hope our dialogue will help to understand the case to those who are not engaged in programming, or just like to think about their favorite activity.
And it all started with a fairly popular question.
- Why is the project development budget often exceeded?
- This is a difficult question. I propose to take as a basis one metaphor that will help me to explain the state of things. Of course this is my opinion, based on the experience that I got.
So, the developers - the creators of new worlds. Virtual worlds.
')
- Would you tell me more about the movie The Matrix!
- Actually a metaphor from there. So here. Input requirements give an idea of what kind of world the customer needs (the customer may be inside the company).
Most often, the requirements are broad and blurry.
- Wait a minute. Why immediately blurry? For example, I have a project that I want to run. I clearly understand how it should work. Moreover, I have TZ !!!
- Hah. Yes, but the customer does not think and should not about many aspects of this new world, because this is the work of developers. How to organize the source code? What convention of naming variables to follow? Which libraries to use? What branching strategy to use? How to provide speed?
By and large, the task of the developer is to lay down such laws in this new world so that this world can solve the original problem. Relate the business or functional requirements to the requirements for the laws of the new world. Moreover, this world must constantly change under the influence of new demands and information.
- Suppose, but what does this have to do with the budget and the timing?
- Let's think what affects the amount of time and, consequently, the budget required to create a new feature on the project?
Well, there is a certain feature. There is a time to figure out how to do it. To implement and test it. And let's say that the developer has all the information about how to do - he knows the necessary technologies, programming languages and approaches perfectly. He understands the requirements - he knows how it should work in the end.
Will the implementation time of the task be equal to the time of writing the code? Of course not. In addition to all this, the developer must embed a new feature into the already existing world. Embed in existing laws. Add new laws or change existing ones, so that both old and new features work.
This is precisely the most difficult, because the complexity of these issues is often much higher than the complexity of implementing the feature itself.
- This is how to build a house? For example, if I want to add another window to the room, should I consider whether there is enough heating? Will I break the laws of heat transfer?
- Exactly. Now imagine that heat transfer is just one aspect. In complex software systems there are hundreds, if not thousands of such aspects. Imagine, when implementing a small new feature, you need to pay attention to all aspects. And only now can I try to explain the main idea. As such worlds (projects) are created and developed, the number of laws and regulations within is constantly growing. It is not so easy to track that some law of this world is outdated and you need to get rid of it.
The world is cluttered with unnecessary rules. Members of the development team begin to live in a more complex world, their labor costs increase.
- And why it is impossible to gradually revise what was done and simplified, to remove too much?
- So it is possible. There are even concrete practices - continuous refactoring and so on. But to conduct self-reflection at the team level is rarely possible, especially at the technical level. Yes, and find all the problems is difficult - the size of the projects more and more. You can only watch that the architecture in the implementation of specific tasks does not become worse.
As a result, the developer lives with the understanding that the task is difficult to solve - after all, many connections need to be rebuilt, in this fictional world of his. Estimates are overstated. Tasks really take longer than they could.
It's like running with a burden - the energy is spent significantly more to overcome the same distance.
- Another scenario - the developers do not overestimate the assessment, because they do not see the increasing complexity, although it is. There are already laws in their world, they just do not know them. And as in real life - ignorance of the laws is no excuse. This leads either to the accumulation of technical debt - there are problems, but they will emerge later. Either the implementation of new features leads to the collapse of other parts of the system, and this may not be immediately noticeable - you do not always double-check all the work and something will come up later (which essentially increases the cost of a particular feature). Oh yeah, auto tests you say - but is it cheap to develop them? Do they test up to 100% performance?
- Come on, I think you will inject - but what about modularity? Even I am not a programmer, I understand how to deal with complexity. Divide into parts. Separate areas of responsibility.
- You're right. This is what most modern programming practices are directed at. For example, maybe you heard about microservice architecture. Developers are trying to reduce the complexity of systems by limiting the scope of responsibility.
But the problems remain the same, just some of them go to another plane - integration. Establishing links between those same modules or services.
I wanted to give you another example of the previous thesis - the difficulty of amending existing laws.
I love to philosophize on this topic. Why is it difficult to see the need for change?
When you created the world, and not just know its laws, they were born by you, it is difficult to perceive things differently. To subject one’s own logic to strong criticism - this is how one can get to schizophrenia. And redrawing these laws can be very difficult. Not always long, but difficult, because it requires a change of some paradigm of this world in the head of a specific developer or the entire team. Imagine that you need to rethink everything in the real world if you change the understanding of the law of gravity. Or for example, suddenly, you found out that the earth is still flat? These are so basic concepts and they are so interwoven into our life that the process of rethinking can take a whole life. And in fact, nothing really changes except your perception of this world. Therefore, developers do not like to change their paradigms. In any case, the majority. It is more comfortable to write more code in the old paradigm than to change the paradigm in order to simplify some particular.
- It seems I'm starting to understand. Of course, it’s hard to try on myself and realize all this complexity just by talking to you, but at least I started to understand the specifics of the work more. Perhaps today I have enough food for thought, but with pleasure I will continue our dialogue at the next meeting ...
And it all started with a fairly popular question.
- Why is the project development budget often exceeded?
- This is a difficult question. I propose to take as a basis one metaphor that will help me to explain the state of things. Of course this is my opinion, based on the experience that I got.
So, the developers - the creators of new worlds. Virtual worlds.
')
- Would you tell me more about the movie The Matrix!
- Actually a metaphor from there. So here. Input requirements give an idea of what kind of world the customer needs (the customer may be inside the company).
Most often, the requirements are broad and blurry.
- Wait a minute. Why immediately blurry? For example, I have a project that I want to run. I clearly understand how it should work. Moreover, I have TZ !!!
- Hah. Yes, but the customer does not think and should not about many aspects of this new world, because this is the work of developers. How to organize the source code? What convention of naming variables to follow? Which libraries to use? What branching strategy to use? How to provide speed?
By and large, the task of the developer is to lay down such laws in this new world so that this world can solve the original problem. Relate the business or functional requirements to the requirements for the laws of the new world. Moreover, this world must constantly change under the influence of new demands and information.
- Suppose, but what does this have to do with the budget and the timing?
- Let's think what affects the amount of time and, consequently, the budget required to create a new feature on the project?
Well, there is a certain feature. There is a time to figure out how to do it. To implement and test it. And let's say that the developer has all the information about how to do - he knows the necessary technologies, programming languages and approaches perfectly. He understands the requirements - he knows how it should work in the end.
Will the implementation time of the task be equal to the time of writing the code? Of course not. In addition to all this, the developer must embed a new feature into the already existing world. Embed in existing laws. Add new laws or change existing ones, so that both old and new features work.
This is precisely the most difficult, because the complexity of these issues is often much higher than the complexity of implementing the feature itself.
- This is how to build a house? For example, if I want to add another window to the room, should I consider whether there is enough heating? Will I break the laws of heat transfer?
- Exactly. Now imagine that heat transfer is just one aspect. In complex software systems there are hundreds, if not thousands of such aspects. Imagine, when implementing a small new feature, you need to pay attention to all aspects. And only now can I try to explain the main idea. As such worlds (projects) are created and developed, the number of laws and regulations within is constantly growing. It is not so easy to track that some law of this world is outdated and you need to get rid of it.
The world is cluttered with unnecessary rules. Members of the development team begin to live in a more complex world, their labor costs increase.
- And why it is impossible to gradually revise what was done and simplified, to remove too much?
- So it is possible. There are even concrete practices - continuous refactoring and so on. But to conduct self-reflection at the team level is rarely possible, especially at the technical level. Yes, and find all the problems is difficult - the size of the projects more and more. You can only watch that the architecture in the implementation of specific tasks does not become worse.
As a result, the developer lives with the understanding that the task is difficult to solve - after all, many connections need to be rebuilt, in this fictional world of his. Estimates are overstated. Tasks really take longer than they could.
It's like running with a burden - the energy is spent significantly more to overcome the same distance.
- Another scenario - the developers do not overestimate the assessment, because they do not see the increasing complexity, although it is. There are already laws in their world, they just do not know them. And as in real life - ignorance of the laws is no excuse. This leads either to the accumulation of technical debt - there are problems, but they will emerge later. Either the implementation of new features leads to the collapse of other parts of the system, and this may not be immediately noticeable - you do not always double-check all the work and something will come up later (which essentially increases the cost of a particular feature). Oh yeah, auto tests you say - but is it cheap to develop them? Do they test up to 100% performance?
- Come on, I think you will inject - but what about modularity? Even I am not a programmer, I understand how to deal with complexity. Divide into parts. Separate areas of responsibility.
- You're right. This is what most modern programming practices are directed at. For example, maybe you heard about microservice architecture. Developers are trying to reduce the complexity of systems by limiting the scope of responsibility.
But the problems remain the same, just some of them go to another plane - integration. Establishing links between those same modules or services.
I wanted to give you another example of the previous thesis - the difficulty of amending existing laws.
I love to philosophize on this topic. Why is it difficult to see the need for change?
When you created the world, and not just know its laws, they were born by you, it is difficult to perceive things differently. To subject one’s own logic to strong criticism - this is how one can get to schizophrenia. And redrawing these laws can be very difficult. Not always long, but difficult, because it requires a change of some paradigm of this world in the head of a specific developer or the entire team. Imagine that you need to rethink everything in the real world if you change the understanding of the law of gravity. Or for example, suddenly, you found out that the earth is still flat? These are so basic concepts and they are so interwoven into our life that the process of rethinking can take a whole life. And in fact, nothing really changes except your perception of this world. Therefore, developers do not like to change their paradigms. In any case, the majority. It is more comfortable to write more code in the old paradigm than to change the paradigm in order to simplify some particular.
- It seems I'm starting to understand. Of course, it’s hard to try on myself and realize all this complexity just by talking to you, but at least I started to understand the specifics of the work more. Perhaps today I have enough food for thought, but with pleasure I will continue our dialogue at the next meeting ...
Source: https://habr.com/ru/post/343324/
All Articles