Brilliant backups landed web developer in big trouble • The Register

When caution becomes a liability

In the world of IT, being thorough and cautious is usually a virtue. But as one web developer discovered, sometimes those very qualities can land you in hot water when others make mistakes behind the scenes.

Meet Neil, a web developer who maintained a website for a client he called "Gerald." For years, their arrangement worked smoothly - Gerald would send changes, Neil would implement them, and Gerald would approve the updates. Everything was running like clockwork until the day Gerald called, absolutely furious.

The website was "wrong," Gerald insisted. Old content was everywhere. Neil checked the site from his end and everything looked perfect. All recent updates were in place. He told Gerald the site was fine.

"Gerald told me what I could do with my perfect website," Neil recounted to The Register.

The mystery of the frozen website

Neil soon figured out what had gone wrong. When he migrated Gerald's site to a new server, Gerald had reviewed and approved it from home - like a normal person would. Neil had left the old site running on the old server, which was standard practice for him. It costs nothing to keep an old site alive, and it makes sense to preserve data until you're absolutely sure it's not needed.

The problem? Nobody had told Neil that Gerald's IT support had hardcoded the old server's IP address into the office's internal DNS. For two whole years, every one of Gerald's 40 staff members opened a browser at their desk and saw the old, frozen-in-time website.

Gerald had never looked at the site from his office during working hours for those entire two years. When he visited the site from home, he bypassed the DNS server and saw the updated version. But once he finally checked it in the office, he saw the old version and assumed something had gone terribly wrong.

The blame game

When Neil finally worked out what had happened and explained it to Gerald, his IT team was present. There were two of them. They listened to Neil's explanation, looked at each other, and then - with the quiet solidarity of people who have broken something expensive - explained to Gerald that actually, the problem was that Neil had left an old website running on another server, which had caused the confusion.

Neil says that was technically true, "in the same way that 'the floor was wet' is a technically accurate description of the Titanic's situation."

"Gerald looked at me," Neil recounted. "And I looked at Gerald. There were two of them and one of me, and they had lanyards."

"You should have deleted the old site," Gerald said.

And Neil did. But not for another four months, just in case.

The moral of the story

This tale highlights a common problem in IT support and development: when something goes wrong, the person who gets blamed isn't always the one who made the mistake. In this case, Neil's cautious approach to data preservation - something that should be considered good practice - became the scapegoat for a much larger issue caused by the client's IT team.

It's a reminder that in complex technical environments, documentation and clear communication are essential. If Gerald's IT team had informed Neil about their DNS configuration, this entire situation could have been avoided. Instead, Neil's diligence in keeping backups and old versions available was misinterpreted as negligence.

For IT professionals, this story serves as both a cautionary tale and a validation of good practices. While it's important to be thorough and keep backups, it's equally important to ensure all stakeholders understand the technical setup and any potential implications of your work.

As Neil's experience shows, sometimes being too careful can still get you in trouble - especially when others are making decisions that affect your work without your knowledge.