Estimates for the time it will take to complete a software development project are notoriously inaccurate. And when I say they are innacurate, they are almost always way too low. Many people who ask for estimates routinely double or even triple what they're given to get a number that is in the realms of plausibility.
(Maybe this is true of other sorts of R&D projects. Many of the same problems apply so I wouldn't be surprised, but I don't have personal experience there.)
Why are software estimates so bad? Because software developers and managers who put together these estimates routinely make absurd assumptions. Assumptions such as:
Software will always be bug-free on the first draft. The programmer will sit down, type in the code, and it will be completely correct. The network will never go down. There will be no hardware problems. We will never have a power failure at our office. No one will ever forget where he put a file and have to search for it.
Of course in real life, this never happens. As a software developer, I've had plenty of times where I had a bug in my code that it took me hours to figure out. Just this week I spent 6 hours trying to import a file supplied by a client into our system. I asked a co-worker who had done this before for help, and he couldn't get it to work either. Finally I figured out that I was using the wrong import function. Go to a different screen, click a different button, and bam, it worked.
Time estimates often treat testing as if it was something we do at the end just to prove that there were no mistakes. They put down a simple straight line: code - test - deploy. No. Testing will almost always find errors. These have to be corrected. Then the corrected code must be re-tested. Often additional errors or new errors are found, which must be fixed and retested. In a complex system, there could be many cycles of this.
It takes zero time to check a program out of the repository, start up the develoment environment, and find the files that you need to work on. When you're done making the change -- with no errors on your first try of course -- it takes zero time to run and test it, check it back in to the repository, deploy it to a test environment, and notify the test department or your boss that the task is complete. There is no paperwork or sign-offs that your organization requires to be done for any of this.
Every now and then a programmer says that some coding change is so simple it will only take 10 or 15 minutes. That is absurd. Even if the change itself took zero time, just walking back to your desk and doing all these before and after tasks takes more than 15 minutes. For a small project, like a minor bug fix, the before and after work may take more time than the real change.
No one will ever be pulled away from this project to troubleshoot a production problem. No one will ever be pulled away from this project to prepare estimates for future projects. No one will take time away to get a cup of coffee or a snack, or to attend a staff meeting, or to talk to HR about the health insurance or retirement plan, or to go to an office party, or to chat with a friend about last night's football game, or to run a personal errand.
And of course, no one will ever get sick or quit or be re-assigned to another project.
Everyone on the team knows everything there is to know about the database engine, the computer languages we are using, the operating system, etc. No one will ever have to take time to look something up or figure anything out. If we are making changes to existing code, everyone on the team has all the existing code memorized, so they know exactly where to go to make any required changes.
In real life, developers often find that they have to research features of the database or language that they don't use often. Sometimes this is a quick look up. Other times they can spend hours trying to figure out how something works.
When changing existing code, just finding the place where you need to make the change can take hours. Figuring out how the current codes works so you know just how to change it can take hours more.
Even though the estimate is based on a brief summary of the requirements, when we receive the full requirements they will not contain any complexity that wasn't obvious from the summary.
I often hear someone get a one or two sentence description of a software development task and immediately announce thtat they can do this in a couple of hours. The reality is almost always that they cannot, because the two sentence summary leaves out all sorts of details and complexity. Like, "A screen to collect the customer's name and address? I can do that in a couple of hours! Just toss up fields for name, street, city, state, and zip, when they click the submit button you write it to the database, and you're done!" Maybe, but probably not. I had such a screen I had to write a couple of months ago. When we got the details, we had rules like: there are three lines for street address, but if the customer leaves a line blank and fills in a line below it, move the data from the lower lines to the blank lines. If the country is the US or Canada, phone numbers must be exactly ten digits, but don't validate phone numbers for other countries. If the customer selects the US, Canada, China, or Australia as the country, then provide a dropdown to select the state or province, filled with the list for that country. For any other country give a text box where the user can type in the state/province name. Oh, and because of touchy political issues, when data is sent to the U.S., Taiwan is a country, but when data is sent to China, if the country was specified as Taiwan, change the country to China and set the province to Taiwan. Et cetera. None of this is ground breaking new advances in computer science, but it all adds to the work that has to be done.
If you asked the average developer, "Do you think that, when you try to write this code, that your first draft will be bug free?", I'm sure they would say, "Of course not." Similarly for other items I've mentioned here. They know all the assumptions are false. But when they put together an estimate, they just don't factor all this in. They make an estimate as if all these absurd assumptions were true.
© 2016 by Jay Johansen
No comments yet.