Where do errors occur in estimating the timing of software projects (based on my own experience)?

Quite a lot of literature is devoted to such an issue as software evaluation (at a cost and / or development time). It is clear that this new discipline (as compared, for example, with metallurgy). And it is clear that mistakes happen here quite often. In this post, I will cite several life stories that could not be taken into account when making the assessment and which influenced the increase in development time.

History about deleting files and folders

When developing a file conversion application, a deadline estimate was made, tasks were written out, and the application was made approximately according to this plan. The program was even tested and implemented (it’s an internal tool for a small team, so nobody flew to the customers on the plane - they just started using it). However, it turned out that periodically an error occurs in the program in which place. The program unpacks the archive into a temporary folder, works with 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 "holds" the files. The program was written on .Net, so the launch time of the garbage collector and other things was not quite obvious - probably the problem was this. As a result, this unforeseen problem took quite a long time - comparable with other tasks of this project. And still we are not sure that this problem has been finally resolved.

History of the introduction of the process and antivirus

Another example in which perhaps many will find out 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 swear at the attempt to introduce into the process and suspicion of viruses. Although there was nothing criminal in that code, the “struggle” with the antivirus required both forces and resources that could be used more adequately.
')

The story of the file dialog

In a simple application (more precisely in the Control Panel Applet, .cpl) somehow it was necessary to show the standard file opening dialog. Surprisingly, when you try to show a file dialog, it is from this type of application that problems arise, due to which the dialog is not shown. How much time was spent searching for a problem and a solution — horror (compared to other tasks). The decision was even worse. I had to make a separate (!) Application to display the file dialog. Only in such a terrible way we managed to do the task.

“Well, you just don’t know how to program!”

the reader may exclaim and will be wrong. The interactions of system components are often so complex that errors and problems occur in unexpected places. Do not believe? Here is the fourth story.

History of broken OpenGL applications

In the development team of a complex OpenGL application, a problem once occurred - the application stopped issuing eye-catching pictures. First of all, all programmers were interrogated on the subject “Has anyone broke something?” Then they rolled back to the previous version - it did not help either. Iron (at first glance) on that machine has not changed. However, later they remembered that a new UPS had recently appeared on this computer. But can this not affect the operation of OpenGL applications? Can. The UPS went to this UPS, which seemed to work as it should, but only with it any OpenGL applications, such as 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 for novice programmers who may even have read the books of Brooks and McConnell, but from their youth they think: “These old men (authors of books) were programming in antiquity, now there are no such problems”. Alas, there are. And there are no prerequisites for the fact that their number will decrease. No libraries, tools (have I really written this?) Will protect you from the fact that you make a mistake in evaluating projects. Therefore, when an experienced colleague or boss will increase your score by two to three times, do not think that he is short-sighted.

Is it always going to be like this?

Most likely no. Just now, software development is too young an industry that lacks decades of proven standards and practices.

In the comments, please share your stories when something unexpected came out while developing.