I read the article “
Why do programmers make wrong time estimates? ”, Which caused me some indignation. Unfortunately, I can not leave a comment, so I decided to write an article in the sandbox.
Actually, the question “
Why ... are they mistaken in estimating deadlines? »Applicable to any industrial activity. And instead of a dot, you can specify anyone (programmers, plumbers, carpenters, mechanics, confectioners, etc.).
This question is part of the problem of interaction between the customer and the contractor. The problem arises around two main questions: “
How much will it cost? "And"
How fast will you do it? ". These questions are as old as intelligent life itself and will be relevant for a very long time.
The most important characteristic of answering these questions is
accuracy , not the minimum time and price, but accuracy, because it determines the success of the project (work, order, etc.).
The author gives some list of causes of errors, but this list is just a special case. If you think well, you can find many more reasons. But all of them are the result of the lack of necessary experience and / or methods of labor-intensive assessment.
In support of this, I propose to consider the reasons given by the author (plus conclusions on how to improve the accuracy of the assessment):
')
1. The
time is clean and dirty . As in any industry, development time is defined as the time spent on preparatory and final measures + time of direct work + time for various losses. Preparatory-final time can be estimated using statistics, most likely it will be approximately the same for any work (deviation 10-15%), the time of the work itself can and must be predicted (but more on that later), the time for various losses seems to be the most difficult but actually everything is simple. This time perfectly correlates with time for the main work, but for each organization this dependence will be different, because it is determined on the basis of the organizational and technical level of the organization. Accordingly, it is necessary to conduct a series of studies for the preparatory and final time and to determine the organizational and technical level of the company in order to improve the accuracy of estimating the total time. Conclusion: knowledge of rationing techniques is necessary.
2.
Performance . There’s nothing to discuss at all, the performance should be constant, the main task of the manager is to monitor this. If productivity jumps, then this is a serious signal to the manager, probably, the potential capabilities of the workers are too high, and they (the programmers) do not correspond to the required level. By the way, this is why enterprises introduce various qualifications (for example, a turner of the third category), they show the capabilities of the employee and his productivity. It often happens that productivity is determined by the most productive employee and then applied to everyone else, which is not always correct. Conclusion: it is necessary to clearly define the qualification, but here you can not do without a good experience.
3.
Research . This reason arises only due to lack of experience or lack of knowledge. And the emergence of such a reason indicates the absence of a design stage, so we have to make design decisions and engage in research in the coding process, naturally this increases the development time. And the absence of the design phase confirms the developer’s lack of experience. Conclusion: improve experience and skills.
4.
Complex systems . This is exactly where experts and / or methods for assessing labor intensity are required. Everything is clear with the experts, but the methodology needs to be selected (perhaps, you can develop your own). You can use, for example, COCOMO / COCOMO II or the method of functional points, but in any case, the ability to use them is required. Own observations - the more complex the system, the less accurate the expert's assessment, and the more effective and accurate are the evaluation methods. On small and uncomplicated systems, assessment techniques give too much error. Conclusion: experts and evaluation methods are needed.
5.
Correction of errors . Errors in the coding process are flaws at the design stage. The ability to competently design can be obtained with experience, or in a good educational institution. Conclusion: you need design experience or a good education.
6.
Composite and atypical tasks . The author says that the assessment of such tasks is based on the self-confidence of the programmer. This is a major error in the assessment. You do not know how to approach the task and accurately assess the laboriousness - do not fuss, do not rely on emotions and intuition, they will not exactly help here. Especially for such situations developed assessment techniques. Conclusion: knowledge of assessment methodologies is necessary.
7.
Evaluation under pressure . But this is not a problem programmer. And here we need not the experience of development, but the experience of negotiations, but it is still needed. Conclusion: it is necessary to get experience in negotiations.
Accordingly, the answer to the initial question “
Why do programmers err in estimating deadlines? "Is very simple.
Programmers are mistaken because they do not have the necessary experience in development and / or do not know how to use methods for assessing the complexity of development . And everything else is a consequence of these reasons.
In general, the article perfectly describes the current situation in the web-industry. New web programmers appear like mushrooms after rain. The experience of such developers is minimal, their knowledge is narrow, ambitions and self-confidence are too high. All of this together makes them make mistakes in estimating terms (labor intensity), but, unfortunately, their mistakes spoil the reputation of the entire community of programmers (and not only the web). Therefore, I think it’s not worth the mistakes of newbies perceived as a problem of the whole industry. And before asking a question to the programmer about the time it is necessary to determine his experience and knowledge. And this is another story.
PS
I do not claim the absolute truth of all my arguments. But, as I have already said, the problems of labor-intensiveness assessment exist in all spheres of production activity. In the scientific school “ Modeling of complex technical systems ” for almost 20 years we have been dealing with various issues in the field of labor intensity, some of them are related to the assessment of labor intensity and are based on the theory of constructive-technological complexity. Unfortunately, all our works are focused on mechanical engineering, but I assure you that in the software industry, the situation with the assessment of labor intensity is absolutely the same. Two years ago I started working on the problem of assessing the complexity of software projects, there are still no results, while the process of analyzing and studying the current situation is in progress. At the moment, the problem of determining the effectiveness of existing techniques and the possibility of using elements of the theory of structural and technological complexity (we call it the theory of complexity) when evaluating the complexity of the manufacture of software products is being solved.
The essence of the theory of complexity lies in the definition of a certain indicator, which gives a quantitative assessment of the complexity of the object. Then, on the basis of the organizational and technical level of the enterprise, the labor intensity in specific production conditions is determined. Further I will not describe, because it is completely from another area.