Error Handling Errors

I fixed a problem today where custom blog software had stopped working after a permissions update. A large number of sites are based upon the blog software and they were all down. Blank page. No errors on screen or in the logs.

This was not software and I came in knowing nothing about it. It might've helped that I do know the developer, but he was offline and unreachable, and no longer with the company for which the software was created. Panic was setting in with customer service.

It's really frustrating when error reporting is turned completely off and no other error handling has been implemented. I knew the problem must be permissions related but there was just no clue as to what file was failing to write. I also knew the application was Zend Framework, which I've been working with for about a year or so. A quick change to the application.ini ...

phpSettings.display_errors = 1

phpSettings.error_reporting = 1

... and I was to see the error and correct the permissions.

This brings to mind: The Log File is Your Friend. Frameworks or applications that implement their own error handling need to also find a way of silently indicating the problem. In this case, it could be done in a custom manner using Zend_Log or by adding log_errors to the php.ini file or to application.ini, like so:

phpSettings.error_reporting = 1024

phpSettings.log_errors = 1

The Shoe is On the Other Foot

I am a pretty good guesser and empathizer. I also have a good imagination. This helps me build Web sites and applications that are useful, thoughtful, and helpful to clients. Most of the time, anyway. It also helps me understand the client's perspective and win more jobs.

But after deciding to outsource the Objective-C portion of our iPhone application, I am now "the client". And the experience has been helpful in understanding even more of the client's perspective.

Timing and Silence

My chief complaint -- if it can be called that -- is getting the job done on time (which we have not) and hearing from the developer on progress (which was good at first but lately has been sporadic). Most of us (developers) are well aware that communication can be an issue, but this experience has really driven home to me the necessity of prompt communication.

• Say something, anything. Never let a message go unanswered, eve if it's just to say "message received". We often feel pressured to have news or progress before responding, but this takes time. Instead, let the customer know you're still there.
• Be up-front about delays. Let the customer know as soon as possible if there's going to be a delay.
• Be open about the current schedule for incoming change requests.

Silence leads to frustration -- don't frustrate your clients.

As a result, I have a new goal for communication with my own clients.

It's a Dirty Hack, But Someone Has to Do It

I had finished a fairly complicated application -- to the client's specification -- that featured a complex system for selecting advertisers for various types of announcements. Although the money was paid, the project lay dormant for many months until the client started selling the ad spots.

Unfortunately, the person selling the spots had been left in the dark on how the system was built and sold the ads in a way that was completely contrary to the current tools -- control panel, automation, and front-end were now incompatible.

I looked at every way possible to make it work within the capabilities of the application but there was no reconciling the way the product was sold and the way the product was built.

To make matters worse, the deadline for the "new" way of doing things was two weeks and I had already had a full plate. I sensed stupid hours in my future, but promised the client I would come up with something.

The more I got in to the code, the more I realized that it was worse than I anticipated. I tried several approaches, but everything was backward in terms of implementation and data that was previously needed in one place was now needed somewhere else -- some where the scope was completely wrong.

I really only had a weekend to work out a solution and the "real" way of doing it would probably take a week's worth of work.

Sometimes you just have to hack something in place. In this case, I bypassed all of the dynamic stuff and just hacked in the raw data for the specific advertiser. Yes, lots of really complicated and fascinating code was essentially discarded for a plain text band-aide that will have to be fixed some day. It wasn't pretty but it was simpler, and more importantly it got the job done quicker.

Sometimes the greatest difficulty in this situation is getting over the fact that you are hacking otherwise excellent code into pieces.

This brings me to yet another truth in programming:

It's a Dirty Hack, But Someone Has to Do It.

You are the best candidate to hack on your own code and when the rubber hits the road, the reality is you just have to do it.

But what can you do to minimize the damage?

1. Leave comments for yourself (or the next guy) wherever you need to change the code.
2. Use @hack or some similar marker so you can easily find the changes and comments.
3. Go back and fix it on a rainy day.