When I walked into his office, Trevor had that evil grin on his face. I knew that I was in for a hard time.
"You remember that our company has been bought out by our international supplier?" he asked. "Well, they have taken a liking to your program, and they want a demonstration CD. It should run on any windows PC."
"I assume then that I cannot install SQL Server on these PCs?" knowing what the answer would be.
"Oh, no!" The grin got bigger.
"I was afraid of that. Never mind. Can we put all of your data on there, or should we set up dummy data?"
"Dummy data. Some of that stuff is confidential, and the salesmen could start handing out the CDs like sweets."
"OK, you will have to help me on that. Will this be a mockup, or do you want a working system."
"A working system."
"I suppose that I will have to put some restrictions in to keep people from just starting to use the program. I suppose that a good plan is to delete everything when the demo is done."
"That is a good idea."
When I got out of his office, I knew I was in for a hard time. The program had been written to work specifically with Microsoft SQL Server. I would have to create a version that would work with a desk-top database. The one that came with Delphi was Paradox, and I saw no reason why not to use that. Unfortunately there are a lot of incompatibilities between the two. This was also a rush job.
The end result was a version of the program that would run from a CD, but had it's own source files. Whenever Paradox worked differently from SQL Server, I created a new source file. A lot of the system was effected. It also meant that changes to the production system did not find their way into the demo system.
My client was happy enough, but I found this profoundly unsatisfactory. I decided that this would not happen to me again.
After some though, I realized that the problem lay with the RAD (Rapid Application Development) architecture of Delphi. This makes it easy to write a screen that accesses a database table. The problem was that there was a direct link between the presentation part of the program, and the database access part of the program. I needed to change the database access part, but the two were completely entangled.
I "knew" of course that this was bad, but this was the first time that I had been bitten so badly by this problem. A good system design must be loosely coupled. This means that the presentation part must know little of the workings of the database access part, and vice versa. Neither must know much about the processing parts of the program, and so forth. Unfortunately I had been seduced by the easy life offered by RAD