Where do the errors in estimating the timing of software projects (based on my own experience) come from?
A fairly large amount of literature is devoted to such an issue as software evaluation (at cost and / or development time). It is clear that this discipline is new (compared, for example, with metallurgy). And it’s clear that mistakes are quite common here. In this post I will give several life stories that could not be taken into account when drawing up the assessment and which influenced the increase in the development time.
History of deleting files and folders
When developing the file conversion application, an estimate was made of the deadlines, tasks were scheduled, and the application was made according to this plan. The program was even tested and implemented (this is an internal tool for a small team, so no one flew on an airplane to customers - they just started using it). However, it turned out that periodically in the program an error occurs in this place. The program unpacks the archive into a temporary folder, works with the files from there, after which the folder is deleted. So sometimes the program “did not have time” to close the files and, accordingly, when deleting, an error occurred due to the fact that someone was “holding” the files. The program was written in .Net, so the start time of the garbage collector and other things was not entirely obvious - this was probably the problem. As a result, this unforeseen problem took quite a lot of time - comparable to other tasks of this project. And still we are not sure that this problem has been finally solved.
History of implementation in the process and antiviruses
Another example in which perhaps many recognize their problems. Everyone knows that antiviruses do not always adequately perceive normal programs. After a small but important change in one of our applications, the antivirus began to repeatedly curse at an attempt to introduce into the process and suspicions of viruses. Although there was nothing criminal in that code, the “struggle” with the antivirus required both strength and a resource that could be used more adequately.
File Dialog Story
In a simple application (more precisely, in the Control Panel Applet, .cpl) somehow I needed to show the standard file open dialog. Surprisingly, when trying to show a file dialog from this type of application, problems occur that prevent the dialog from being displayed. How much time was spent searching for a problem and solving it - horror (compared to other tasks). The decision was even worse. I had to make a separate (!) Application for displaying a file dialog. Only in such a terrible way was it possible to do the task.
“Well, you just don’t know how to program!”
the reader may exclaim and will be wrong. Interactions between system components are often so complex that errors and problems occur in unexpected places. Do not believe? Here is the fourth story.
The story of broken OpenGL applications
The team of developers of a complex OpenGL application once had a problem - the application stopped issuing eye-pleasing pictures. First of all, all the programmers were questioned on the subject of "if someone broke something." Then they rolled back to the previous version - this also did not help. Iron (at first glance) on that machine did not change. True, they later recalled that a new UPS had recently appeared on this computer. But can this not affect the operation of OpenGL applications? Can. A driver came to this UPS, which seemed to work as it should, but only with it any OpenGL applications, for example, games, did not work. Removing the driver solved the problem.
Why all these stories?
I am sure that experienced developers and managers in these stories will not be able to find something new. They know all this from their own experience. These stories may be useful to novice programmers, who may even have read Brooks and McConnell books, but in their youth they think: “These old people (authors of books) programmed in antiquity, now there are no such problems.” Alas, there are. And there are no prerequisites for their number to decrease. No libraries, tools (did I really write this?) Protect you from the fact that you are mistaken in evaluating projects. Therefore, when an experienced colleague or boss increases your assessment by two to three times, do not think that he is short-sighted.
Will it always be like this?
Probably not. Just now, software development is too young an industry in which there are no decades of proven standards and practices.
In the comments, please share your stories when something unexpectedly came out during development.