Matt Peperell's Blog

Don’t name things new or old!

Systems are replaced in IT often (though perhaps not as often as we might sometimes like or that they deserve!). Some of the time, these old and new systems will co-exist. Given enough time, such a system might even be replaced a second time, maybe with some of the same staff members present and even by the same staff members.

When in the middle of such a transition, how can the old and new systems¹ be distinguished?

The example I’ll focus on here is a print spooler but it need not be limited to that.

A separate name might well be needed if someone consuming these print services (or whatever) cannot automatically select the correct destination. Calling the print queue printserver makes sense. But when replacing it, giving the new system the name newprintserver though in the short term it allows the two to be distinguished, will eventually lead to confusion once the old one gets removed.

Let’s assume for the moment that the name newprintserver has been decided upon, and that it’s sufficiently far in the future that the old one has been removed. Will the newprintserver system be renamed? If so then this can cause another series of disruption whilst configuration is updated.

Maybe it won’t be renamed from newprintserver once the old system has been removed, but this has a couple of drawbacks:

• newcomers(!) joining the organisation might wonder whether the old one is still in service (for example as a backup) or maybe even that the new one is still in a trial period and therefore not ready for full use
• What happens when the newprintserver system is itself replaced? Will the next one be called newnewprintserver? This is hyperbole, I admit, but hopefully this makes the point.

The other approach is to use the name printserver for the new one and to rename the old one to be oldprintserver. Because when new systems are introduced they often have teething problems, it’s usually the case that the two systems co-exist. But by using the prefix old- might make people think it’s already due to be phased out and is deprecated. But it also causes problems because in the event of the new system not yet fully working, people are guaranteed to have to make a configuration change to go back to the original printer which they knew to be working.

With the goal being to migrate people onto the new system, this is perhaps the least disruptive version of the previous scenerio, but still might result in the double renaming if there are teething problems with the new system which necessitates people to use the old one for a while.

Better to have the one rename, and to do so once it’s been proven. As much as one tries to perform testing before launching a new service, some things will be missed. But you can help to cut down on this impact by inviting a few users to be beta testers, perhaps who promise to be flexible and who can give you useful feedback and are willing to help diagnose issues.

Aside from system replacement, having a few users with whom you have a such a good relationship will make easier your life as a person who provides services to end users.

tl;dr

Don’t name things new or old.

But what name to use? Cute names might be fun, but they are also opaque. So names such as marypoppins, hyperion, saturn are best avoided. Descriptive names are better. So when replacing a system called printserver use a name such as printer or printspooler.