Why do we continue to break deadlines

Obvious things need to be written over and over. So that they do not lose their evidence in the eyes of people. So that people who are driven by the oppression of reality cannot deny the obvious as irrelevant. So that they could not come up with clever pseudo-arguments to justify their disregard for obvious things. Obvious things do not forgive. And project planning is no exception.





There is a lot of literature on project management written, but there is no right answer for the most burning question. And most likely will not. I will try to devote this post to the most boring way to describe the causes of the sad state of people seeking 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 being done for some purpose, in any case it is considered so, and in any case, anyone, even the most unreasonable project, can try to attribute some goal. All the same with programming. If you are engaged in programming not only for yourself, and you are not in the cozy universe of open-source, you’ve probably noticed people around you who are trying to get an answer from you by hook or by crook when you’re finally done. Someone says that these people are customers, someone is Timlides, some even say that this is a project manager. Speaking bluntly, who is this person and when he asks his uncomfortable question - no one knows.

Only one thing is authentically known - the more times a person asks this question, the more indignant his voice is, and the more pressure he will try to exert on you. The task would seem clear, but the specificity of the question does not allow to answer it. Here the reasons vary - and depend on the experience of the respondent. A less experienced person is inclined to believe that he does not know the answer to this question. A more experienced person is often tormented by suspicions that he will not be able to give such an answer that the questioner would like, and therefore a battle takes place in his soul between the sincerity angel and the tact demon (however, theological roles may vary depending on the situation and the respondent’s goals).

Statistics show that whatever answer is given, it turns out to be either wrong or unacceptable.

View from the outside

One of the greatest obstacles in the understanding of people who ask and programmers who answer is that people who ask themselves imagine writing software code as a process identical to the production process of something material. And whatever the managers say (in trying to attract a client), trying by hook or by crook to prove that scheduling when developing software is a matter of exact and usual, there is a difference here, and therefore the approach should be different.

The trouble is that this is one of those situations where people would prefer to hear a pleasant lie, rather than an unpleasant truth. And if you try to absolutely truthfully tell the client that you do not know how long the project will take, and try to explain why it’s impossible to set the deadlines, then the client will most likely go to your competitors who have called the deadlines. However, you should not be upset here - your competitors do not know the dates either.

In this situation, you can understand everyone. The client wants to give money and get the result, he sincerely does not care how you do it, he just needs guarantees that you will do it and 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 get an order. As a result, everyone has problems: you are out of work, the client does not receive the project on time, competitors receive an 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? These are expenses of time, which include development of design, selection of raw materials, element base, creation of production lines. Production is the amount 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 an ideal world. In the real world has its own characteristics. Take a look around you - almost all the objects that surround you are a product of mass production. For computers, refrigerators, apartments, cat trays and bicycles, repeated use of the results of the design phase is typical. 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 design stage. Grinding the part is a time-determined process, assembly of the node is also, etc. Summarizing all these terms, you can get the exact date of release of the final product (within the framework of errors). Enough isn’t it enough? The simplicity adds to 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 a standard product, then they need to find a specialist who could modify the product or make it from scratch. With the corresponding costs of design and their work.

The culture of consumption is here, and all people understand the difference between a mass product and a product made to order. Including the difference in the delivery time of both. And in general, people have the impression that problems need to be solved with available means. And they decide them that way. Idyll - not otherwise.

In the case of programming, everything turns upside down. First, the design phase in fact never ends - no matter how close the end of the project is, you will still need to look for solutions that there is a creative process, which means there is no smell in time determinism. To build an extremely accurate model, even an online store and keep it in your head, no one can afford. We have to constantly think out the details. And no specs are of help here - they only say what needs to be done, but not how. The question “how” can be answered by a drawing, but, ironically, in the case of software, it is the finished program.

Secondly, the need for constant decision making is due to the fact that the client in most cases involves the development of custom-made, 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 means, again, a waste of time.

Thirdly, usually the programs cannot be (as of January 2013) developed by the conveyor method - programmers cannot be replaced as imperceptibly as workers at the factory. No, really can not! 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, an illusion may arise that an employee can be replaced imperceptibly. Outwardly, it is imperceptible - it is possible, but a 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 us to a loss of time. Changes in the team of programmers is a natural phenomenon.

Copying a program is analogous to the stage of production in the material world. In practice, it is absolutely irrelevant for obtaining a product. All forces go to the development stage, much more labor-intensive, and most importantly, poorly predictable.

Time speculation

Almost all customers do not want to work with the non-deterministic model of supply, and they do not have an understanding that the software product that they want to receive is not produced, but is invented on the go. And the thought process is rationed badly. But guarantees and certainty would be all the same. The bad news is that most customers cannot and do not want to understand this. And it’s hard to explain - would you believe the arguments of one person that there is no answer when there are 10 more people who are ready to give this answer?

Speculation on guessing the term has long been firmly established as a tool of competition, and the term itself has already ceased to mean something. What is the point of determining what is in principle impossible to determine? What is the point of telling the truth to a person who does not want to hear it? The fact that for some projects it’s still possible to define the deadline adds fuel to the fire, and as a result, the client, looking at how quickly and clearly set up his 1C or promotional website, begins to think that such a time evaluation mechanism will be work for other projects ...

Triumph of punctuality

Having reached this place, a certain circle of readers might begin to suspect the author of low competence, which he is trying to justify by setting the task of determining the project's deadlines in unsolvable light. Not at all! I in no way deny that it is possible to determine the deadline for the delivery of the project. But let's be honest with you.

Is there a lot of programming in creating the same type of business cards / online stores / android clients? In the case of a streamlined technical process, where the differences between projects are minimal, the timing will be accurate. This overlooks the fact that the entire design phase has already been completed. Even some programmers are keeping up with this situation, retaining in their minds the firm conviction that in all software projects the timing is real.

Does your project take more than a month or two? Usually on such dates the error is not very large, the project is small and the errors in measuring time are the same. However, they are - if you completed a project in six weeks instead of a month or two, then you are seriously mistaken. Your predicted timeframe did not coincide with the real one - and what will happen if you extrapolate it to projects of longer duration?

If you still think that defining exact dates is possible, then either you are a genius, or you should experimentally change the subject area of ​​programming to check whether your predictions 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, then at least not less than the actual development time, then there are only two options - an excessive safety net and a change in task conditions.

The first approach is a classic when you take the development time and multiply it by ... the number that your intuition tells. This is not to say that this method is bad, the only thing that can be reproached for it is the lack of optimality. However, in the light of the fact that the timing is often inversely proportional to the likelihood of receiving a project, this method cannot be called universal.

When it is not possible to gain time with an increase in time, you should try to change the project conditions so that they are as close as possible to the developments you have or ready-made solutions. Some share of certainty it will make. For good, this method should be applied to all projects published on non-specialist freelancing. In order to increase the degree of adequacy and save money of these same non-specialists, as well as the nerves of specialists.