I think a much simpler solution to testing installers is just to use VMWare or similar. Just click a button, and seconds later you've got a "fresh" install. The full version allows you to create snapshots - I use these to test against OSes in various states of update: SP1, SP2, SP3, etc. Great stuff. Only downside is that it almost by definition should not be used for applications that interact heavily with the hardware: drivers and realtime apps and such. Eric

Make and Model might help. I have had problems like this myself - usually it's a bug in the firmware that causes it to crash after a long period of time, or when a certain sequence of packets goes through it. I've had routers that were fixed with a simple firmware update, so check to see if there is one available. And I've also had routers that had no fix, so I had to toss them in the trash and buy a different model. I've pretty much restricted myself to Cisco these days - they seem to have a more thorough Q/A department.

Eric Cox, Software Architect Tometa Software, Inc. http://www.tometasoftware.com Get stress relief at http://www.mrtometahead.com

"design patterns, handling the class responsibilities etc." Keep in mind that, until relatively recently (~1994), the term "Design Patterns," didn't exist. The patterns themselves existed, but they didn't have commonly used names. I've been programming for 27 years, so when I learned all these patterns, they were just known as "good architecture." When I started my current job, one of my colleges was steeped in these design patterns, and when we would talk programming, he'd throw out these terms all the time, and I wouldn't know what he was talking about. Turned out all of the design patterns are just things that I already know and use. I just didn't know the commonly-used terminology for them.

Mr. Webster is a very successful rancher, so his orkers were all busy, out in the fields orking the cows. They could not be reached for comment.

Mr. Webster disagrees: http://www.merriam-webster.com/dictionary/co-worker[^]

When I worked for Hewlett Packard, we looked upon reviews and criticism as valuable feedback, and thanked the giver. This should be made part of the company culture. It worked extremely well at a company known for its quality. When you bring this up to the boss, emphasize the idea that useful feedback is the best way to write flawless software (and therefore save $$$). The "mine is bigger than yours" review is less than useless - it actually hurts the culture of the company, and puts the reviewed person on the defensive, so he/she is less likely to change the software for the better, and more likely to "dig in" and find ways to advocate for "their way".

Eric Cox, Software Architect Playxpert, LLC. http://www.playxpert.com