 |  |  |
| Main | |
Discarded Software #2: Standard Practice Fails
Mountains of Discarded Software is an essay I wrote in 1999 posted here in four parts. This part describes the problem encountered during design and requirements analysis when the customer and the software developer proceed according to percieved standard practice and how that fails them.
When the contract is awarded, the customer has only a vague idea of what is needed. As the overall design takes shape, it is standard practice for the software developer to ask the customer to sign off on requirements. Unfortunately it is often a painful process illuminating the disconnection between these parties. The developer who has been awarded a contract and has the support of senior customer personnel often meets what he construes as resistance among the ranks of the future users. These are people trying to protect their ability to do their job and may be right to view the whole process with consternation due to experiences in the past.
When someone is accustomed to dealing with one solution no matter how poorly suited (say they know a key sequence like ctrl-j 6 shift-F tab F4 to kick off a routine process) it is not necessarily in their best interest to have to learn another system that is not guaranteed to be much better. There may be subtle nuances of the old system which allow non-obvious ways of manipulating the data. These are generally things that the customer is not conscious of, they just know how to get the job done. Developers need to value the information and learning that has gone on before their heralded arrival on the scene.
The developer also must be aware of strain within the customer's camp between the management that is pushing the new system and those who have to operate it. This can get exacerbated when it inevitably becomes clear that version 1.0 won't do everything that the customer was hoping, or that different groups within the customer camp were hoping.
Another stumbling block is that it seems like developers and customers generally assume that the goal is to get a computer program to do what the customer is doing. Not the case! Computers are only good at some things the customer is doing. And the point I want to make is that its up to us the developers to know this.
Unfortunately, it is standard practice to try to do all of the design at the beginning, or at least take into account all of the future possibilities. It is commonly felt that it is more efficient to overhaul an entire system at once rather than change it one piece at a time. But the fact is that no one is very good at designing the complete overhaul! What we invariably end up with is a software system that is developed as a whole and then whomp! It is installed and customers are trained and then everyone scrambles to try to make it work. Whether or not it is eventually rejected, it sets the customers back a few days or a few weeks, but hey that's progress!
The next part of this series is called "A Design To Love."
| Main | |
