Software Development: Avoiding Disasters
Horror stories abound with news of projects that result in software disasters: The statistics are frightening – billions of dollars have been wasted on software projects with cost overruns, that finish late, do not meet user expectations, and are outdated before they commence.
This used to relate only to mainframe projects where the scope was large and the software complex. With the powerful Servers and PCs that are available today, large and sophisticated systems are being created. With sophistication comes complexity – these projects are now just as prone to a software disaster as with a mainframe.
Estimating how long a software development project should take is not an exact science. It involves personal experience and a lot of guesswork
Management Development Expectations
Management, quite rightly, require a definite timetable for development. They need to be able to determine the costs involved, and the resources that are needed.
As the developer cannot provide any degree of certainty, all estimates need to be made conservatively. Allowance should be made for the inexact nature of software predictions. And this needs to be communicated to management.
It is not unknown for management to attempt to extract the most optimistic of estimated times. Worse still, the phrase "estimated completion date" will somehow be understood as a "definite completion date". A different approach is needed – one that is not open to misinterpretation.
Optimistic Software Estimations
Human beings are optimistic creatures. No matter how bleak reality is, there is always a bright side, a silver lining, a Pollyanna-esc view to be held. This is especially true of software estimation. If all goes exactly as predicted, the project will come in on time. Unfortunately, 95% of the time, unanticipated problems will cause a delay.
"Oh, it's just a few hours' work" – frequently turns into several days' hard labour. Which Visual Basic programmer has not been guilty of this? The "few hours work" may have taken into account all the predictable factors. But then there is the unpredictable – when a routine just will not work. Is it the network? Was it a Microsoft security update? Has the latest service pack been installed? Has the user done something unexpected?
For a small task, the consequences of an underestimate may be trifling. But for a large project, when the very existence of a company is threatened, much more conservative estimates are needed. What is required is a contingency allowance to be applied to the initial "most reasonable" time estimate. The contingency allowance should, at a minimum, result in a 50% chance of the project completing on schedule. This means that half the time the project estimator will be a hero, and half the time a villain.
A more professional approach would be for the Visual Basic analyst to set a contingency allowance resulting in success 95% of the time. Of course the estimated completion time would be dramatically increased.