>Charlie, if you could see the legacy system I am working on now as a hired gun you would be laughing and slapping your thighs. For example --
>
>1. Several page PRGs? Shirley you jest! That's nothing. How about over 10,000 lines? And some of them in methods of alleged classes, not in PRGs.
>
>2. Controlling colors with @ SAY commands.
>
>3. Menus handled the same way. It's like going to a museum.
>
>4. Bonus points: some of the menus have over 20 choices. With over 20 CASE statements to handle the choice, lines of code roaring on page after page like the Mississippi River after a hurricane.
>
>4. There is no standardized method of saving and restoring the environment in a called module. The closest it comes (in some of them) is to save the currently selected work area, its index order, and its record pointer upon entry and restore them upon exit. That is so unreliable given the vagaries of the approximately one bazillion called modules that I was advised to reopen any tables you need under different aliases so you don't F up the calling program.
>
>5. The main form most users work with is so overloaded with functionality, different data being placed at the same spots on the screen depending on the exact menu choices (see above), you can't be sure what's where without firing up the debugger. Colors go bold or plain according to their own inscrutable whims. A given user who doesn't just do the same thing over and over could easily not see the same data layout again the rest of the month. This is pure poetry.
>
>6. The main table in the application -- a DBF, natch -- the table that stores the lifeblood of the entire business, is named the HD table. That stands for Hard Drive. Because it's stored on the hard drive. Actually it's stored on the network now -- onward!
>
>7. The application itself is called by users "the work screen." Because that's where they do their work.
>
>8. Another key table is named AAA.dbf. It stores payments and adjustments, which are differentiated by a type code. Living together like brethren in one table. That whirring sound you hear is Dr. Codd spinning in his grave.
>
>9. Have we mentioned hard coding? Always the first resort. If it's client XYZ and this is a payment and it's within three days of the full moon, and my shoe size is greater than 10, then do one thing. Else do another thing. Always implemented in code. Metadata, who needs it?
>
>Are we having fun yet?
>
>

You didn't have to showoff like that. Always the same guys that have the best jobs :-D