Monday, July 21, 2008

Training, Testing and Production

The prevailing school of thought (at least where I've worked) has been to keep your trained and untrained users as separated as possible. Don't get me wrong-- if you have deep pockets, and can get separate servers for production, training and testing environments, then by all means go for it.

But the truth is that once people have shelled out money for the database and web servers on the production side of the fence, they start looking for ways to cut expenses. This usually happens by the time they get round to setting up the training server. "Well, can't we just use one server for both the training server AND the testing server?"

This is a really bad idea, for many reasons. A training server needs to be able to handle a set number of users simultaneously (30, 60, etc.), while a testing/development server can get by with handling a much smaller number of simultaneous users. This translates into a horrible training experience for your newest end users/customers-- horrendously long login times, slow updates between pages, etc. The first impression your new users get of your killer web app is in the training, and you're showing them a slow moving piece of turd, ok?

Then, as if that weren't bad enough, developers are always working on the test/development server-- trying to add the new functionality that they've received back from program analysts/customer feedback. If you're lucky, all the new code works great the first time and there are no bugs-- but we all know how unrealistic that is. New code means new bugs, until you take measured steps to locate and remove them. So now, in addition to showing your newest end users a slow application, you're also showing them new, untested code that might or might not have bugs in it.

What exactly do you have against your new, untrained users anyway? ;)

Last, even if there aren't any bugs in the code (lucky you!), the addition of new features typically means that there are new buttons and gadgets in the interface-- so what your end users are being exposed to in their training session isn't identical is look and feel, or even in operation, to what they will actually have to work with in the production environment.

And you wonder why none of your end users likes the whole web development process?

No comments: