Originally written in 2010
It’s hard to believe it’s been almost five years since I worked for a certain online flower retailer. Back then, I was senior developer on a team in charge of the company’s legacy order processing system: a green-screen application. For you kids out there, that means our customer service reps would log into their brand new screaming-fast Compaqs and open up puTTY to connect to our server over telnet. Monochrome text. 80 characters across by 25 characters down.
Like many apps of its kind, our customer service software was based off numeric menus and single-character commands: P to print, R for refund, and Q to quit. Pretty straightforward, right?
Remember how I said this was an online retailer? Don’t worry, this technological colossus was only in charge of our back-end stuff. The actual web pages were served off of a farm of servers hosted off-site…in another country, actually. Orders would feed from the web servers to our new back-end system which was just starting to take over some of our system’s work, and then the new system fed into ours.
And this arrangement worked great 99.99999% of the time. Orders went straight from the website, through our system, and out to the filling florist without any human intervention. It was a great system. It was a damn great system. You might say in most cases it just worked. But sometimes a human needed to intervene, and a missed keypress here or misunderstood business rule there, and your order could get pretty messed up. And then it became our problem.
Aside from being highly skilled, incredibly handsome, and excruciatingly professional programmers, my team was a bunch of troubleshooting ninjas. In fact I would hazard to guess that 99.99999% of the time messed up orders that we dealt with turned out to be user error and not our code. The hard part was proving it.
One of our programmers built an Easter egg of sorts, what came to be known as the W screen. To this day I’m still not sure what the W stood for, but I think it was what the heck did this order look like when it arrived on the legacy system?. It took our logged copy of the order transmission, parsed out the individual fields, and displayed them. The screen was coded in less then an hour, but it saved us countless hours trying to deal with issues during the busiest times of the year.
Then one normal, unassuming day I was asked to provide an estimate for a change request. Customer Service wanted usability enhancements to one of their most important tools. You guessed it: the W screen. Someone mistyped Q to quit and ended up at W for what is this amazing screen that wasn’t listed on the menu?
I tried to push back, arguing that this was an internal tool that they weren’t supposed to have access to. But it was too late. We did the project. We enhanced the W screen for them, and then we added another secret debugging screen that was even harder to find, because sometimes you just have to.
In the history of software development, entire volumes could be dedicated to features like the W screen. Apple dealt with a similar crisis when iOS 4 came out lacking field test mode, a secret screen for Apple and AT&T employees to see a phone’s signal strength. And even though its just a bit of laughs, there’s serious talk about removing WordPress’s the matrix has you Easter egg. It’s scaring the hell out of some developers’ clients, but some people just don’t want to let it go.
So, if you’re adding a secret feature to your product, whether it’s an internal app on an outdated platform or the hottest smart phone on the planet, be sure to hide it well. Because someone is sure to find it, and then people will depend on it, and then it becomes their feature, not yours.
