Desktop engineering, part three

Desktop engineering is the set of activities that strive to create a broadly used baseline desktop environment that is consistent and verified.

A couple of other things I wanted to say about this definition before moving on to other topics:

Consistent: One of the goals of desktop engineering is consistency. Consistency may be boring when it comes to suburban crackerbox houses or mainstream pop music, but it is great for computers. In IT support, boring is your friend, because boring means that your support costs go way down. This is because your process makes new machine set up a practical no-brainer, and every machine is a known, familiar quantity. When faced with a problem, your technicians don't have to worry about whether the tech who set up the machine remembered to add this software or tweak that registry setting. You know that it was done, because it is part of your documented, enforced setup procedure. Your support technicians consequently spend so much less time checking that the basics have been covered, and can move directly to solving the real problem.

There are levels of consistency. There is apparent consistency, and there is true consistency, and you should strive for the latter and avoid the former. True consistency is having machines that have the same software installed the same way, with the same configurations. Apparent consistency enforces things like a common screensaver, desktop arrangement, etc. Forcing desktop conformity can backfire. I think that if you enforce conformity in the desktop customizations, some people will feel a need to express their individuality and will lobby for Administrator rights just in order to be different. I say, let the users have their unusual wallpaper, and focus on making sure that all of the DLLs match.

Consistency does have its downside. When all of your desktop computers are the same, a problem seen on one computer is more likely to be seen on all of your computers. This means that a larger percentage of your problems will be enterprise wide, and so they will be the responsibility of the engineers to fix. This is where verification comes in.

A bigger issue (to my engineer's mind) is the perception that all problems are the responsibility of the engineers to fix. This can mean inappropriate escalation of problems to your most experienced (and expensive) staff. Procedures must be implemented to ensure that only problems that are related to the engineering of the desktop "make it" to the desktop engineers.