Marvin’s company had a problem. Their C++ application tended to throw out a lot of error codes. That was actually okay- that application had a lot of possible failure modes that it couldn’t do anything about other than cough up an error and quit.
The problem was that their customers weren’t particularly happy with messages like: Error: QB57, since it told them absolutely nothing. “RTFM” was not an acceptable response, so someone had to add some functionality to turn those cryptic error codes into meaningful messages.
W.T.F. Community College hired a team of highly-recommended web design consultants to bring its website in to the 21st century. Paul was tasked with overseeing their work and supporting the new site upon go-live. After a couple months of grinding, they cranked out a beautiful new site that was accessible, navigable, and responsive. It also removed the old site's dependence on Flash, replacing it with a titanic mound of PHP and JavaScript that was run by Apache.
Paul and his team gave it a thorough beating in their test environment and everything seemed solid. They even gave a demo of it to the the head of W.T.F. Community College, President Skroob. He was able to easily find his way around, sign up, set his password to 1-2-3-4-5, and register for fake classes. It got the Prez's official salute of approval. The amazing new website was ready to be launched in time for the fall semester.
The first day of classes rolled around and suddenly everything didn't seem so rosy. President Skroob frantically burst in to the IT office shouting "The web site is down! The web site is down!" A quick check of the monitoring system didn't show anything wrong, and manual inspection didn't either. The server hosting the site was hardly breaking a sweat. No pressure on CPU, RAM, or I/O. Paul tried browsing to the site and the browser just hung. No errors, no nothing.
Go-live day for the new CabinetWorld redesign was a tense, hurried affair. Developers streamed in at 5:00 AM, hoping to catch wind of early problems before most of the country awoke and started shopping. True to form, the overworked break-room coffee machine gave up the ghost at 5:10, but luckily, at 6:00 the boss brought in doughnuts, and by 6:30 a Starbucks run had been arranged. Everyone huddled in the war room, nervously watching the monitors as the number of concurrent visitors rose steadily. And then ...
One of the things a good developer should always strive for is efficiency. Slow code should be improved if possible. Complicated steps should be simplified or removed. Finding a poorly-implemented process which is costing company time and streamlining it is usually a good thing, and means more profits, which means larger paychecks and bonuses, and happy bosses. Right?
It’s not uncommon to have a branch in your code along the lines of, if (debugMode) { doSomeLogTypeThingy(); }. Usually, we try and wrap that sort of stuff up and keep it far away from the actual business logic, and the result is a plethora of logging frameworks and diagnostic libraries.
They are, however, consistent about one thing: whether or not debugMode is enabled or not, the actual business logic should behave the same way. They’re designed and intended to be minimally disruptive.
