Why we will continue to disrupt the deadlines
Obvious things need to be written over and over again. So that they do not lose their evidence in the eyes of people. So that people driven by the oppression of reality could not reject the obvious, as insignificant. So that they could not come up with ingenious pseudo-arguments in order to justify their neglect of obvious things. Obvious things do not forgive. And project planning is no exception.
A lot of literature on project management has been written, but there is no right answer for that most burning one. And most likely it will not. I will try to devote this post to the most boring to describe the reasons for the sad situation of people who are looking for support and support in their attempts to answer one of the most important questions of software development: how long will it take?
Everything in our civilization is done for some purpose, in any case it is customary to think so, and in any case, any, even the most unreasonable project, can be tried to ascribe some purpose. That's the way it is with programming. If you are engaged in programming not only for yourself, but also do not reside in the cozy open source universe, you probably noticed people around you who by hook or by crook are trying to get an answer from you when you are finally done. Someone says that these people are customers, others are team leaders, some even say that this is a project manager. Speaking directly, who this person is and when he asks his uncomfortable question - no one knows.
Only one thing is known for certain - the more times a person asks this question, the more indignant his voice is filled, and the more pressure he will try to exert on you. The task, it would seem clear, but the specificity of the question does not allow him to answer. Here the reasons vary - and depend on the experience of the responder. Less experienced is inclined to believe that he does not know the answer to this question. A more experienced person often turns out to be tormented by suspicions that he will not be able to give such an answer that the questioner would like, and therefore in his soul there is a battle between the angel of sincerity and the demon of tact (however, theological roles may vary depending on the situation and goals of the responder).
Statistics show that no matter what answer is given, it turns out to be either incorrect or unacceptable.
One of the greatest obstacles to understanding people asking and programmers responsible is that people asking imagine writing program code as a process that is identical to the production process of something material. And no matter what managers say (in attempts to attract a client), trying by hook or by crook to prove that scheduling timelines in software development is an exact and ordinary thing, there is a difference, and therefore the approach should be different.
The trouble is that this is one of those situations where people would rather hear a pleasant lie than an unpleasant truth. And if you try to tell the client absolutely truthfully that you don’t know how long the project will take, and try to explain why it is impossible to set the deadlines, then most likely the client will go to your competitors who named the deadlines. However, you should not be upset here either - your competitors also do not know the timing.
In this situation, you can understand everyone. The client wants to give money and get a result, he sincerely does not care how you do it, he just needs guarantees that you will do it and will do it by a certain date. You do not want to lie to a person that is worthy of all praise. Your competitors just want to receive an order. As a result, everyone has problems: you are sitting without work, the client does not receive the project on time, competitors receive indicative genocide of nerve cells and a unique opportunity to work much more with the same budget.
Each production conditionally has two stages: product development and its production. What is development? This is a waste of time, which includes design development, selection of raw materials, components, creation of production lines. Production is that period of time devoted to the transformation of drawings and raw materials into the final product. Forgive me couch and graduate economists.
Such a simplified model is in some way valid both for creating material products and for writing programs. In a perfect world. The real world has its own characteristics. Take a look around - almost all the objects around you are a mass-produced product. Computers, refrigerators, apartments, cat trays and bicycles are characterized by repeated use of the results of the development phase. Those. according to one drawing and a well-established technical process, a huge number of products are produced, the release date of each of which is prescribed and justified at the development stage. Turning a part is a time-determined process, assembly of a node, too, etc. Summarizing all these terms, you can get the exact deadline for the release of the final product (within the margin of error). Simple enough isn't it? Simplicity is added by the fact that people understand that, they choose from the available models on the market, and that if they want to get something different from the standard product, then they need to find a specialist who could modify the product or make the required one from scratch. With appropriate design costs and their work.
The culture of consumption is present here, and all people understand the difference between mass goods and goods made to order. Including the difference in delivery times of both. And in general, people get the impression that the tasks need to be solved by the available means. And they solve them that way. Idyll is not otherwise.
In the case of programming, everything is turned upside down. Firstly, the design phase, in fact, never ends - no matter how close the end of the project is, you still need to look for solutions that there is a creative process, which means that it does not smell of determinism in time. To build an extremely accurate model of even an online store and keep it in the head of no one can do. You have to constantly think up the details. And no specifications are helpful here - they just say what needs to be done, but not how. The drawing can answer the question “how”, but, ironically, in the case of software, it is a ready-made program.
Secondly, the need for continuous decision-making is due to the fact that in most cases the client implies custom development, i.e. even with ready-made modules and developments, it is not always possible to simply take and assemble them together - changes are almost inevitable. And where there are changes, there are almost always regressions, which again means a loss of time.
Thirdly, usually programs (at the time of January 2013) cannot be developed in a conveyor way - programmers cannot be replaced as discreetly as factory workers. No, they really can't! In a small team, the loss of time from changing or leaving the developer will be obvious. In a huge company, where there are tens and hundreds of programmers, the illusion that an employee can be discreetly replaced can arise. Outwardly imperceptible - it is possible, but the loss of time is inevitable, since any new programmer will not be able to immediately enter the development process and will have to examine the existing code of the predecessor, which again leads to loss of time. Changes in the command staff of programmers is a natural phenomenon.
Copying a program is an analogue of the production stage in the material world in practice, it is absolutely not significant for obtaining a product. All forces go to the development stage, which is much more laborious and, most importantly, poorly predicted.
Almost all customers do not want to work with a non-deterministic supply model, and they have no understanding that the software product that they want to receive is not produced, but is invented on the go. And the thought process is poorly normalized. But guarantees and certainty I want anyway. The bad news is that most customers cannot and do not want to understand this. And explaining this is difficult - would you yourself believe the arguments of one person that there is no answer when there are another 10 people nearby who are ready to give this answer?
Speculation on guessing the term has long been firmly entrenched as an instrument of competition, and the term itself has already ceased to mean anything. What is the point of defining what is in principle impossible to define? What is the point of telling the truth to a person who does not want to hear it? Oil is also added to the fact that for some projects, the deadline is still realistic, as a result of which the client, looking at how they quickly and clearly set up 1C or made a promo site, begins to think that such a mechanism for evaluating deadlines will be work for other projects too ...
Having reached this place, a certain circle of readers will probably begin to suspect the author of low competence, which he is trying to justify by setting the task of determining the timing of the project in an unresolved light. Not at all! In no way do I deny that it is possible to determine the deadline for the completion of the project. But let's be honest with ourselves.
Is there a lot of programming in creating the same type of business card sites / online stores / android clients? In the case of a streamlined technical process where the differences between the projects are minimal, the timing will be accurate. At the same time, it is overlooked that the entire design phase has already been completed. Even some programmers are led to this situation, leaving in their heads the firm belief that in all software projects the assessment of deadlines is a real thing.
Does your project take more than a month or two? Usually, on such terms, the error is not very large, the project is small and the errors in time measurements are the same. However, they are - if you completed the project in a month and a half instead of a month or two, then you were seriously mistaken. Your predicted period did not coincide with the real one - what will happen if you extrapolate it to projects for longer?
If you still think that determining the exact dates is possible, then either you are a genius or you should experimentally change the programming domain to check if your forecasts will come true with the same accuracy as in the current field of activity.
If you want your forecast to be, if not accurate, at least not less than the real development period, then there are only two options - excessive safety net and change of task conditions.
The first approach is a classic, when you take the development time and multiply it by ... the number that your intuition tells you. This is not to say that this method is bad, the only thing it can be blamed for is non-optimality. However, in light of the fact that the amount of time is often inversely proportional to the probability of receiving a project, this method cannot be called universal.
When it is not possible to redeem with the extension of time, you should try to change the project conditions so that they are as close as possible to your existing developments or ready-made solutions. It will bring some degree of certainty. For good, this method should be applied to all projects published on freelance by non-specialists. In order to increase the degree of adequacy and save money of these same non-specialists, as well as the nerves of specialists.
A lot of literature on project management has been written, but there is no right answer for that most burning one. And most likely it will not. I will try to devote this post to the most boring to describe the reasons for the sad situation of people who are looking for support and support in their attempts to answer one of the most important questions of software development: how long will it take?
Formulation of the problem
Everything in our civilization is done for some purpose, in any case it is customary to think so, and in any case, any, even the most unreasonable project, can be tried to ascribe some purpose. That's the way it is with programming. If you are engaged in programming not only for yourself, but also do not reside in the cozy open source universe, you probably noticed people around you who by hook or by crook are trying to get an answer from you when you are finally done. Someone says that these people are customers, others are team leaders, some even say that this is a project manager. Speaking directly, who this person is and when he asks his uncomfortable question - no one knows.
Only one thing is known for certain - the more times a person asks this question, the more indignant his voice is filled, and the more pressure he will try to exert on you. The task, it would seem clear, but the specificity of the question does not allow him to answer. Here the reasons vary - and depend on the experience of the responder. Less experienced is inclined to believe that he does not know the answer to this question. A more experienced person often turns out to be tormented by suspicions that he will not be able to give such an answer that the questioner would like, and therefore in his soul there is a battle between the angel of sincerity and the demon of tact (however, theological roles may vary depending on the situation and goals of the responder).
Statistics show that no matter what answer is given, it turns out to be either incorrect or unacceptable.
View from the outside
One of the greatest obstacles to understanding people asking and programmers responsible is that people asking imagine writing program code as a process that is identical to the production process of something material. And no matter what managers say (in attempts to attract a client), trying by hook or by crook to prove that scheduling timelines in software development is an exact and ordinary thing, there is a difference, and therefore the approach should be different.
The trouble is that this is one of those situations where people would rather hear a pleasant lie than an unpleasant truth. And if you try to tell the client absolutely truthfully that you don’t know how long the project will take, and try to explain why it is impossible to set the deadlines, then most likely the client will go to your competitors who named the deadlines. However, you should not be upset here either - your competitors also do not know the timing.
In this situation, you can understand everyone. The client wants to give money and get a result, he sincerely does not care how you do it, he just needs guarantees that you will do it and will do it by a certain date. You do not want to lie to a person that is worthy of all praise. Your competitors just want to receive an order. As a result, everyone has problems: you are sitting without work, the client does not receive the project on time, competitors receive indicative genocide of nerve cells and a unique opportunity to work much more with the same budget.
Two processes
Each production conditionally has two stages: product development and its production. What is development? This is a waste of time, which includes design development, selection of raw materials, components, creation of production lines. Production is that period of time devoted to the transformation of drawings and raw materials into the final product. Forgive me couch and graduate economists.
Such a simplified model is in some way valid both for creating material products and for writing programs. In a perfect world. The real world has its own characteristics. Take a look around - almost all the objects around you are a mass-produced product. Computers, refrigerators, apartments, cat trays and bicycles are characterized by repeated use of the results of the development phase. Those. according to one drawing and a well-established technical process, a huge number of products are produced, the release date of each of which is prescribed and justified at the development stage. Turning a part is a time-determined process, assembly of a node, too, etc. Summarizing all these terms, you can get the exact deadline for the release of the final product (within the margin of error). Simple enough isn't it? Simplicity is added by the fact that people understand that, they choose from the available models on the market, and that if they want to get something different from the standard product, then they need to find a specialist who could modify the product or make the required one from scratch. With appropriate design costs and their work.
The culture of consumption is present here, and all people understand the difference between mass goods and goods made to order. Including the difference in delivery times of both. And in general, people get the impression that the tasks need to be solved by the available means. And they solve them that way. Idyll is not otherwise.
In the case of programming, everything is turned upside down. Firstly, the design phase, in fact, never ends - no matter how close the end of the project is, you still need to look for solutions that there is a creative process, which means that it does not smell of determinism in time. To build an extremely accurate model of even an online store and keep it in the head of no one can do. You have to constantly think up the details. And no specifications are helpful here - they just say what needs to be done, but not how. The drawing can answer the question “how”, but, ironically, in the case of software, it is a ready-made program.
Secondly, the need for continuous decision-making is due to the fact that in most cases the client implies custom development, i.e. even with ready-made modules and developments, it is not always possible to simply take and assemble them together - changes are almost inevitable. And where there are changes, there are almost always regressions, which again means a loss of time.
Thirdly, usually programs (at the time of January 2013) cannot be developed in a conveyor way - programmers cannot be replaced as discreetly as factory workers. No, they really can't! In a small team, the loss of time from changing or leaving the developer will be obvious. In a huge company, where there are tens and hundreds of programmers, the illusion that an employee can be discreetly replaced can arise. Outwardly imperceptible - it is possible, but the loss of time is inevitable, since any new programmer will not be able to immediately enter the development process and will have to examine the existing code of the predecessor, which again leads to loss of time. Changes in the command staff of programmers is a natural phenomenon.
Copying a program is an analogue of the production stage in the material world in practice, it is absolutely not significant for obtaining a product. All forces go to the development stage, which is much more laborious and, most importantly, poorly predicted.
Speculation of time
Almost all customers do not want to work with a non-deterministic supply model, and they have no understanding that the software product that they want to receive is not produced, but is invented on the go. And the thought process is poorly normalized. But guarantees and certainty I want anyway. The bad news is that most customers cannot and do not want to understand this. And explaining this is difficult - would you yourself believe the arguments of one person that there is no answer when there are another 10 people nearby who are ready to give this answer?
Speculation on guessing the term has long been firmly entrenched as an instrument of competition, and the term itself has already ceased to mean anything. What is the point of defining what is in principle impossible to define? What is the point of telling the truth to a person who does not want to hear it? Oil is also added to the fact that for some projects, the deadline is still realistic, as a result of which the client, looking at how they quickly and clearly set up 1C or made a promo site, begins to think that such a mechanism for evaluating deadlines will be work for other projects too ...
The triumph of punctuality
Having reached this place, a certain circle of readers will probably begin to suspect the author of low competence, which he is trying to justify by setting the task of determining the timing of the project in an unresolved light. Not at all! In no way do I deny that it is possible to determine the deadline for the completion of the project. But let's be honest with ourselves.
Is there a lot of programming in creating the same type of business card sites / online stores / android clients? In the case of a streamlined technical process where the differences between the projects are minimal, the timing will be accurate. At the same time, it is overlooked that the entire design phase has already been completed. Even some programmers are led to this situation, leaving in their heads the firm belief that in all software projects the assessment of deadlines is a real thing.
Does your project take more than a month or two? Usually, on such terms, the error is not very large, the project is small and the errors in time measurements are the same. However, they are - if you completed the project in a month and a half instead of a month or two, then you were seriously mistaken. Your predicted period did not coincide with the real one - what will happen if you extrapolate it to projects for longer?
If you still think that determining the exact dates is possible, then either you are a genius or you should experimentally change the programming domain to check if your forecasts will come true with the same accuracy as in the current field of activity.
What to do?
If you want your forecast to be, if not accurate, at least not less than the real development period, then there are only two options - excessive safety net and change of task conditions.
The first approach is a classic, when you take the development time and multiply it by ... the number that your intuition tells you. This is not to say that this method is bad, the only thing it can be blamed for is non-optimality. However, in light of the fact that the amount of time is often inversely proportional to the probability of receiving a project, this method cannot be called universal.
When it is not possible to redeem with the extension of time, you should try to change the project conditions so that they are as close as possible to your existing developments or ready-made solutions. It will bring some degree of certainty. For good, this method should be applied to all projects published on freelance by non-specialists. In order to increase the degree of adequacy and save money of these same non-specialists, as well as the nerves of specialists.