Title: Waterfall versus RAD

I am not sure what the purpose of this short article is. It is either to air my prejudices for and against waterfall verses rapid-prototype-development (RAD), or it's an excuse for my attempt to call myself 'professional' rather than a cowboy. Whatever it is, this is an experience I have suffered, and a problem shared...

Where I started from was a recent call for help from a local business. As I am between contracts, a week's local work would be very welcome. They had purchased, when they started 7 years ago, a simple application for their type of business from a similar business in a neighbouring town. What they purchased is a difficult question, but I assume that what they purchased was the 'right to use' rather than the rights to the copyright of this simple database application. The program itself was written by the owner of this other firm for their own use and had also sold copies to half a dozen other firms in the area. No copyright notice can be found in the application, no documentation was ever provided (license, user, code, test - nothing). The company has 'stopped trading' and the owner disappeared.

What my client wanted was some support, the original program was a Lotus Approach Database (6 tables with 300+ fields in total) and they could find no one locally, or nationally, whom would even quote for the job. (They've been asking me for over two years, but I've always had a contract until this time of trying!). They, like many small businesses, just want this apparently simple program to work. The only other company who have responded to their calls for help were a local training firm who could provide training in Access, £600 for 10 hours training. But they were not prepared to perform the job itself and would not guarantee that my client would be able to after the training was over. As all the people they had contacted have said 'Lotus Approach, is that like Microsoft Access?', they want the application converted to Access on the assumption that more people know Access so they should find it easier to get support in the future (who knows?). I tried to explain that I did not think that they'd get any more support for the application in Access vs. Approach, but converting it is what they want.

My next problem was then, should I reverse engineer the application in order to perform the required actions for my client? As my client is also a musician I contrasted their application with that of sheet music, so we agreed that the copyright issues had to remain with their company and that really I could not get involved (my feet were getting cooler). They had actually offered me the possibility of increasing my income from the job by allowing me to sell the new application! (I politely refused this kind and generous offer).

I then tried to explain to my client that we did not have any form of requirements or functional specifications. They countered by saying that they knew the business logic very well and could explain everything to me as and when required. So I told them that for a project, even this small and apparently simple, I'd expect to have about a foot of bookshelf space of documentation. Furthermore, that I usually work under the direction of a project manager and they agreed that this was not them. It was at this point that they realised that this was not such a simple task. But after all, all they wanted was to convert this simple (302-field database) from Approach into Access and add a search facility to the phone-number field.

Further more, I ask how I was supposed to test the application once it was ported without any test specification. That's ok, they said, the current program works "because I've been using it for 7 years and I know it works". I then hypothesised 'what if' the invoices were out by one pound? In the first year they might not notice, that the next year cash flow may be a bit tighter, but ten years later they may be out of business? So they asked how I'd usually test such an application. I said that I might write (yet) another program, probably of similar size, to generate ten years worth of records and to add up all the records to cross check the results. A few moments of reflection and they told me of an existing bug, that there is a discrepancy between batch generated invoice totals and the same invoice (re-)generated singularly - Oh joy thought I.

So, then I contrasted this simple job with a building; I suggested that a real builder needs plans, probably from an architect, and has at minimum the local building control inspectors to inspect their work. I also pointed out that if one employs cowboys, at your own direction (the cowboys don't accept liability), that you may end up with what you wanted, but you may not. My client also had a limit of £1000, but they had purchased a copy of Access (as I pointed out, the converse may not have been true of the Approach license, and I said that ignorance was no excuse in the eyes of the law). I told them that I could put them in touch with a local cowboy programmer who would probably not have such qualms and as they definitely charge less, they might get what they wanted within their price limit. They then asked me if I thought they'd be able to do the job - I declined to answer as I could not guarantee the cowboy's standard of work . When I got home I started to think about the traditional waterfall method, which is what I am accustomed to, versus the hip-and-trendy RAD approach. The latter must be the closest to the way in which someone had generated the original application, embedding their business knowledge and logic into the application as they went along. What gives me the right to want so much more?

As Steve McConnell points out in his excellent (but now slightly out of date) 'Code Complete' [McConnell], the one and only part of any software job that will be done, is that of 'construction', all other phases of development can/will/are negotiable. Also in [McConnell] pp 519/520, presents a 'Project Formality Worksheet', this describes a good metric for recommended documentation. It only takes a few minutes to complete, so I scored my clients application as a '12' (the lowest possible score!), so the (US DOD) recommendation is "User Manual & incidental program documentation ... plus database specification if applicable". [if you do any project management read the book & use this quick metric]

So, I believe I need a Database Specification - easy to reverse engineer from the Approach Database; my client does not need any User Documentation because they 'know how it works' (its only got 6/7 screens). All that leaves is testing and migration. But what amazes me, is that my client has been using this program for 7 years without any qualms, as have (presumably) the other 5/6 users. For my client the bugs are not so important as they employ a bookkeeper, whose books are taken as the true state of the company.

What should I do? I can't take the job without the cost going way over my client ceiling. I won't put my name to a half-baked job that is untested, but if I don't take the job they'll end up with a cowboy. The last time I took a cheap local job the 'nice' people declined to pay my last invoice, but they are a shabby little software/hardware outfit. [My wife, formerly of the construction industry, said that the practise of withholding the last invoice was common as did our legal advice. The 'client' has the work complete and can make extra profit by ignoring the contractor(s) last invoice.] I'm sure that this client will pay but I feel like I'm holding them over a barrel.

Should I attempt to pass this onto a junior? Don't even think about increasing a company from yourself(ves) to a member of the public, the red tape, legal requirements and employment costs in this country are horrendous! So I agree to coach an employee of their firm in Access, in order that the employee could do the work. It turns out that the application only required four tables with a total of 42 fields. The original database had lots of replicated fields in each table, because there were fields which coincidentally had similar names, and looking up one value from one table, the 'logic' looked up the same value in another table; there was no relations constructed in the database! The original author also had two tables just so that they could generate unique (incrementing) index values!

One of my reactions is that two can play at the game of not paying the last invoice when it comes to software. With a little care you can place a time limitation on the software (no need to tell the suspect client) and remove it when the invoice is paid. Of course if it isn't paid the 'client' will wake up one day to find the software does not work. With a little care over the wording of your contract you can make this legally watertight. (Something along the lines:

All rights to use the commissioned program remain with the author until completion of agreed payments.

or

No guarantees as to performance of the product apply prior to completion of payment.

Francis