Vote with your wallet, my next SSD will be a samsung.

Is anyone actually surprised by these poll results?

Wake me up when it is pitch-able, hit-able and the size of a baseball. It would make our "national pastime" exciting to watch.

It might actually be easier to essentially embed this in a clear plastic soccer ball. You'd want to add a radio tx to stream the images out so you could have a "ball-cam" in the live feed. Maybe instant replay would be good enugh. With a spinning ball you'd need one hell of a fast shutter to cut out the blur.

Kernel of a good idea worth a big pile of cash but they have a long way to go.

Maybe those two LOC are is really, really, really bad.

Java... ok, why not. I would take a look at Cassandra and Zookeeper to get the ball rolling. You'll need a good load balancer; nginx or haproxy since I don't know of a good one in Java. I assume a bunch of tomcat servers for the actual app. I suppose jboss messaging to keep with the java theme.

You can get all that on one machine for development, then for deployment you can flexibly adjust the number of db servers, queue servers, load balancers and app servers based on anticipated load. If you're extra-cool you can deloy to a cloud and dynamically allocate servers as-needed.

Been there, done that. Got the t-shirt. It's fun. Enjoy it.

Spend an extra day or two thinking about exactly how you're going to handle logging. It will be worth it.

Tough but true.

The best you can do is make sure your own code is clean and clear. Eventually the contrast will be noticed and management should step in to figure out how to overall improve code quality. In theory they will consult with the developers that have demonstrated good practices. It is quite possible, even likely that no one will care.

You do your job. You write your code. If you do well you may end up managing a team. Then you can implement whatever kind of quality control you feel is appropriate.

The only truly meaningful metric is customer satisfaction. After each ticket is closed send a survey email to the user. If your team plows through enough tickets you get a statistically significant success % per tech that you can compare to the other techs.

Without knowing a lot more about the nature of tickets it is hard to give a better response. It might be very important to gauge the difficulty (trivial-hard) and novelty (common-rare) of tickets but it could also be a waste of time. Does one tech plow through dozens of tickets a day or a few? Are the techs specialized? Anything email related goes to joe, hardware issues to tom, etc.. Are the tickets auto-generated from emails, called in or do they fill out a web form?

Given the size of the team the company thinks 1) you aren't getting the job done, 2) one or more people on the team are dead weight or 3) you are overworked and need more people. I wouldn't bet on #3.