Notes on saving money
The prime rule of professional computer system development appears to be “Never time to do it right. Always time to do it over.” There are a number of reasons for this, including pressure to get to market or to have a corporate project online well before there is an understanding of what needs to be done. Indeed, of the eight main causes of project failure, five involve requirements definition, three are management issues, and none are technical issues.
This tells us several things:
First is having an understanding of what needs to be done, in terms of solving a problem, which has nothing to do with technology. This being the case, no matter how much time you have budgeted for that phase, you need more.
Second is that you are probably going to get right those thing you know about, and probably going to get wrong those things you don’t know about.
Third is that if you are only able to do those thing you know about, acceptance of the system should be based on those things you know about, and not on those things you don’t know about. In practical terms this means that you should be developing test data before you begin implementing the system. A project is acceptably done, from the development point of view, when you put the test data in and get back the preplanned test results.
Fourth is the recognition that at some point you are most likely to discover some of the things that were undiscovered in the requirements definition phase, and have to deal with them.
As an example of how difficult requirements definition can be, imagine that you need to develop a system that takes as input the lengths of the sides of a triangle, and returns the type of triangle (equilateral, isosceles, right, scalene, or not a triangle at all). How many tests do you need to do in the program? I am told that it requires thirteen tests, and that a good analyst should come up with seven, which means that almost half the tests will not be done. If it is this difficult to get the proper requirements for a program this simple, imagine how hard it is to get an entire system right!
The same thing holds true with security. You need to have the requirements as close to right as possible, and do the advance work as well as possible, while still recognizing that you can never get it entirely right, and that at some point you may have to deal with problems that you could never have foreseen. But the closer you are to getting it right from the start, the better off you will be.
