I liked your analogy to bookkeeppers that decline an accountant. Most BIG companies will not hire a controller or accountant unless they have bookkeeping experience.

I can tell you that my approach to clients was to get the application done by deadline and fix issues afterward. Perhaps the wrong approach.

The best way to test an app is to get a room full of skilled developers with big ego's and challenge them to make it break!

That being said:

Why test after completion? With a self contained modular approach - beta ready modules are delivered for the customers review while the "outer" layers of the app are being built.

Example - for a sales order system - you need an inventory as well as an order entry. The inventory can be built - all the reports added and functions added - and the user can test or enter inventory items while the order entry module is being developed (destroyed?:-).

That way the user can request changes and help test - and get an idea of how the app will behave.

I've winessed projects where nothing is delivered until the project is "complete" and they were disasters - deliveries take 4 times as long as promised and were unsatisfying (I thought the problem was VB - but it was really an inexperienced development team!:).

This is the strategy of logoed corporate teams who develop the project top down (through management) rather than the troops on the ground that actually have to use it. A perceived advantage is that the system shop can blame the problems on managements lack of experience (they told us to do it that way).

The success of a project is not based on managements interetation - it's all based on the user's reactions. User's have a veto - if they don't like what management puts in front of them - the project will fail or extend beyond it's depreciation schedule and be dropped.

Advice: Work projects bottom up - write self contained modules - deliver the innermost or core modules first - then make changes as you write the wrappers. You've been at MS too long:-)! You'll get back into the groove - it's just like riding a bicycle!:)

It it's always good to ask the "troop" how they expect the app to work - and then suck up to them. If the troops don't like - management won't like it and the project will fail. The only time I talk with the suits is when I make the proposal and when I send my bill. The time I don't spend coding I spend learning how to communicate with the people who will really determine the success of my project - those computer clerks and users.

The value of an employee is not how much time they spend inside an app - but how much time they spend being people. The better an app - the less time the user will spend using it!





jskoziol@msn.com with deeper insights.