Tie your shoelaces and pull up your pants!
So what slows down software development?
Think about this question for a second. As it turns out, the longer you develop something, the more difficult and unpleasant it is to add new features to your application, drank the architecture?
And why did tasks have been solved so easily before, and now they look confusing and difficult to implement?
')
It would seem that the situation should improve, because you have been in the project for a long time, haven't you? Why is it the other way around?
Well, do not blame yourself for the fact that the answers do not pop up in your head by themselves, most developers suffer the same. Yes, and questions, you see, not easy.
If we knew all the answers, then there would be no problems.
Nevertheless, you will often come across managers, customers and even other developers who continue to search for answers to these same questions without success.
And first of all, everyone starts to blame the process. After all, it is obvious that problems with the process adversely affect the speed of development.
It makes sense. However, I discovered that this is often not the root of your problems. If the team is not sitting idly, and important tasks are properly prioritized, then most likely the process is not guilty.
I want you to understand me correctly here. That is, two things that I mentioned are not the only things that should bother you, I just try to say that since most of the time the team really works on things that are really important for the project, you can’t magically manage the processes, although This is markedly increasing the productivity of the team development (in most cases).
Considered and such options:
Of course, these are all wonderful questions that you should ask yourself from time to time, but I am constantly convinced that there is another forgotten problem ...
Let's do a little experiment.
Forget about all the processes, forget about the scrum and backlog and story points and everything else.
You are a developer. You need to do the task set for you, change something in the code. You sit alone, there are no processes, analysts. Only you and your work.
You can think about something that you have done recently or are developing right now, I just want you to abstract from everything that does not directly relate to the design or coding of this feature.
Surely you will have something like this:
1. This feature is implemented quickly and simply, I know how and where to add it, everything will be type-top!
That's great! So, in fact, you have no problems.
2. Something I do not understand what needs to be done. How and where will it be used in the system?
Hmm, in this case, you most likely have some problems with the process. Maybe you need to set the task more honorably or you need to ask more questions. It happens, really. Ideas-semi-finished products get into the process and someone will definitely have to run and move their brains before the developers can actually do them.
3. I am afraid to change something, it is almost impossible. Before you begin, you will need to dig into other parts of the application and figure out what works, how and why (and how it should work at all).
Sadly, this is the most likely outcome. Something in between the second and third points, because they have the same reason - ready-made code and either dead or “her-no” architecture.
And I continue to face the fact that the development of most applications is slowing down due to the code of the applications themselves or the loss of the original design.
But you will see similar problems only in successful companies, because ...
There was a time I consulted a couple of failed startups. And I must say, they had one thing in common (as was the case with most other startups): zero problems with the code. Yes, an excellent code base, combed, well-groomed, it smells nice.
I have seen the best architecture and perfect code in dead startups.
Maybe it looks like I'm contradicting myself. Now I will explain.
The problem is that startups with sparkling code do not keep up with the market. They stand at the start and tie beautiful bows on their shoelaces, look around and carefully examine each place where they are going to put their foot.
What's happening? They create great code, cool architecture. But too late. The competitors rush forward and the two obscured non-very-programmers-but-I-kodil cheerfully bypass you with their application on VB6, written last night on the knee . Yes, it may not be exactly what the customer wanted, but how quickly!
But what, am I really saying now that you need to write a napkin govnokod and quickly hand it over, otherwise fail?
Or do I say that it is impossible to grow a successful office on good practices and high-quality code?
Not. But I try to say that most successful companies first of all focused their efforts on the customer and only then on software.
In other words, if you look at the code of a dozen successful companies over the past five years, in 9 of them you will find a shitty architecture and system very distant from the original design and good manners.
Okay, what am I doing all this?
Winning companies run and survive! However, even after 5 years, they still continue to run their best, and then their ugly shoelaces begin to untie.
They may not even realize that their shoelaces are untied until they stumble over them a couple of times. Nonsense, they still continue to run. On the one hand, this is good, because this is what makes them prosperous, while others that they decided to stop and, left far behind, to tie their cords, are shamefully losers.
The problem usually makes itself felt after about five years of continuous running, when companies decide that it is time to go to a new level. Until now, they had a good run, wagging from side to side and trying to keep their legs apart enough to really not get on the laces.
This is just a little slowing them down and therefore they continue to run, violently riveting features and splashing saliva.
And now from shaking their pants begin to fall! But serious companies have no time to slow down for no reason and start pulling up their sliding pants!
From the side it all looks very positive. They blush, give all the best in order to continue to run at the same speed, but flat pants and untied laces are enough to make the run turned into awkward fast walking. An old lady with weights on her ankles gives them a head start , but they are still too busy to take a break and pull up these pants! And since last time, they have not yet made up!
And then they begin to think. What to do? How to solve the problem, not slowing down and not pulling up the pants once again? Improvisation begins. They are trying to jump. Someone even comes up with the idea that they need more legs ... =)
I think you get the idea. In fact, you only need ...
I hope that the analogy is clear and now you understand what is happening with the stagnant architecture and the musty system code.
While you rush with all the dope, your shoelaces are untied, and your trousers are steadily beginning to fall off, all this seriously makes you slow down.
And it will worsen until you finally discover that you are actually moving backwards.
Unfortunately, I do not have a magic answer. If you can accelerate, scoring on the architecture and design of the system as a whole, then sooner or later you will have to pay and register everything in a normal way.
Perhaps you will start from scratch. You may have to combine all your forces to bring everything in order. In any case, you have to stop. Although maybe someone tried to tie shoelaces on the run? =)
Do not worry, you have not done anything wrong. Moreover, you survived the time when others were too careful and failed. Just do not ignore your pants, in which you are confused at every turn, do something terrible!
Note Translation: I am not a translator, I am the same as everyone else, so a more or less free translation came out. I tried to convey the irony of the article. Please, write about typos and shortcomings in PM. Thank you for your attention and have a nice day!
Think about this question for a second. As it turns out, the longer you develop something, the more difficult and unpleasant it is to add new features to your application, drank the architecture?
And why did tasks have been solved so easily before, and now they look confusing and difficult to implement?
')
It would seem that the situation should improve, because you have been in the project for a long time, haven't you? Why is it the other way around?
Looking for answers
Well, do not blame yourself for the fact that the answers do not pop up in your head by themselves, most developers suffer the same. Yes, and questions, you see, not easy.
If we knew all the answers, then there would be no problems.
Nevertheless, you will often come across managers, customers and even other developers who continue to search for answers to these same questions without success.
And first of all, everyone starts to blame the process. After all, it is obvious that problems with the process adversely affect the speed of development.
It makes sense. However, I discovered that this is often not the root of your problems. If the team is not sitting idly, and important tasks are properly prioritized, then most likely the process is not guilty.
I want you to understand me correctly here. That is, two things that I mentioned are not the only things that should bother you, I just try to say that since most of the time the team really works on things that are really important for the project, you can’t magically manage the processes, although This is markedly increasing the productivity of the team development (in most cases).
Considered and such options:
- Pair Programming?
- Change Scrum to Kanban?
- Shouldn't we define backlog otherwise?
- Maybe we should use parrots to evaluate tasks? Story points? Or even let all backlinks be the same size?
- Do we need more developers? Or business analysts?
- Is it worth reorganizing teams?
Of course, these are all wonderful questions that you should ask yourself from time to time, but I am constantly convinced that there is another forgotten problem ...
YOUR CODE!
Let's do a little experiment.
Forget about all the processes, forget about the scrum and backlog and story points and everything else.
You are a developer. You need to do the task set for you, change something in the code. You sit alone, there are no processes, analysts. Only you and your work.
You can think about something that you have done recently or are developing right now, I just want you to abstract from everything that does not directly relate to the design or coding of this feature.
Surely you will have something like this:
1. This feature is implemented quickly and simply, I know how and where to add it, everything will be type-top!
That's great! So, in fact, you have no problems.
2. Something I do not understand what needs to be done. How and where will it be used in the system?
Hmm, in this case, you most likely have some problems with the process. Maybe you need to set the task more honorably or you need to ask more questions. It happens, really. Ideas-semi-finished products get into the process and someone will definitely have to run and move their brains before the developers can actually do them.
3. I am afraid to change something, it is almost impossible. Before you begin, you will need to dig into other parts of the application and figure out what works, how and why (and how it should work at all).
Sadly, this is the most likely outcome. Something in between the second and third points, because they have the same reason - ready-made code and either dead or “her-no” architecture.
And I continue to face the fact that the development of most applications is slowing down due to the code of the applications themselves or the loss of the original design.
But you will see similar problems only in successful companies, because ...
Sometimes it is necessary to run with laces untied.
There was a time I consulted a couple of failed startups. And I must say, they had one thing in common (as was the case with most other startups): zero problems with the code. Yes, an excellent code base, combed, well-groomed, it smells nice.
I have seen the best architecture and perfect code in dead startups.
Maybe it looks like I'm contradicting myself. Now I will explain.
The problem is that startups with sparkling code do not keep up with the market. They stand at the start and tie beautiful bows on their shoelaces, look around and carefully examine each place where they are going to put their foot.
What's happening? They create great code, cool architecture. But too late. The competitors rush forward and the two obscured non-very-programmers-but-I-kodil cheerfully bypass you with their application on VB6, written last night on the knee . Yes, it may not be exactly what the customer wanted, but how quickly!
But what, am I really saying now that you need to write a napkin govnokod and quickly hand it over, otherwise fail?
Or do I say that it is impossible to grow a successful office on good practices and high-quality code?
Not. But I try to say that most successful companies first of all focused their efforts on the customer and only then on software.
In other words, if you look at the code of a dozen successful companies over the past five years, in 9 of them you will find a shitty architecture and system very distant from the original design and good manners.
So, what about the pants?
Okay, what am I doing all this?
Winning companies run and survive! However, even after 5 years, they still continue to run their best, and then their ugly shoelaces begin to untie.
They may not even realize that their shoelaces are untied until they stumble over them a couple of times. Nonsense, they still continue to run. On the one hand, this is good, because this is what makes them prosperous, while others that they decided to stop and, left far behind, to tie their cords, are shamefully losers.
The problem usually makes itself felt after about five years of continuous running, when companies decide that it is time to go to a new level. Until now, they had a good run, wagging from side to side and trying to keep their legs apart enough to really not get on the laces.
This is just a little slowing them down and therefore they continue to run, violently riveting features and splashing saliva.
And now from shaking their pants begin to fall! But serious companies have no time to slow down for no reason and start pulling up their sliding pants!
From the side it all looks very positive. They blush, give all the best in order to continue to run at the same speed, but flat pants and untied laces are enough to make the run turned into awkward fast walking. An old lady with weights on her ankles gives them a head start , but they are still too busy to take a break and pull up these pants! And since last time, they have not yet made up!
And then they begin to think. What to do? How to solve the problem, not slowing down and not pulling up the pants once again? Improvisation begins. They are trying to jump. Someone even comes up with the idea that they need more legs ... =)
I think you get the idea. In fact, you only need ...
Stop, tie the laces and finally pull up your pants!
I hope that the analogy is clear and now you understand what is happening with the stagnant architecture and the musty system code.
While you rush with all the dope, your shoelaces are untied, and your trousers are steadily beginning to fall off, all this seriously makes you slow down.
And it will worsen until you finally discover that you are actually moving backwards.
Unfortunately, I do not have a magic answer. If you can accelerate, scoring on the architecture and design of the system as a whole, then sooner or later you will have to pay and register everything in a normal way.
Perhaps you will start from scratch. You may have to combine all your forces to bring everything in order. In any case, you have to stop. Although maybe someone tried to tie shoelaces on the run? =)
Do not worry, you have not done anything wrong. Moreover, you survived the time when others were too careful and failed. Just do not ignore your pants, in which you are confused at every turn, do something terrible!
Note Translation: I am not a translator, I am the same as everyone else, so a more or less free translation came out. I tried to convey the irony of the article. Please, write about typos and shortcomings in PM. Thank you for your attention and have a nice day!
Source: https://habr.com/ru/post/151110/
All Articles