>>It may not matter. Recognizing the requirement and delivering a solid solution (zested with a little sex appeal) overwhelms this kind of detail.
>
>Until it crashes.
Solutions that crash have little (if any) sex appeal. The cheesiess culprits are management-down designs. The management team looks at the data, ignores the desktop workflow (and the desktop user), lays out forms (in Powerpoint (or sumpin), to show the "suits";etc) and then sends it to the coding bench.

Eventually the project is delivered to end user for testing. The end user then says : "Well it needs to do this or that ..", and so on. Thats always seems to be where those types of projects start eating clock and budget.

It seems, in many cases, that work flow and "end user" input are the last considerations for (some) projects.

We have initiated projects where client's management attempts to describe what they need (and control the project). We listen, but do not begin actual design until we have developed a relation with the slug(s) pounding the keyboards. If you give them (the slug) a DOS program that does the job (and never breaks), they would be happy. They have no vanities regarding object or procedural (or whatever) - they just want to deliver their stuff/reports (to their bosses) in a timely and accurate manner. Make the slug look good, management will look good - thus we will look good.

Have you ever walked into a project where the "consultants" before you, simply migrate an FPW2.6 project to VFP. Uuuuugly:). Or wrote a VFP version that behaved the same as the FPW project it replaced. Twenty million forms with two million files, and countless repetition of the same SELECT procedures throughout.

Then there are the developer/programmers that slober with pride when they say "Our program has over 500,000 lines of code". Makes you wonder - was that by intent - or just a lack of planning or laziness or "Maybe you should have kept your food service job:)

Alas - Jim - I rant too much :)