We Don?t Need Decoding!

Hot off my "We Don?t Need Encoding" post comes this gem (**edit: the question marks in the title of my encoding posts are intentional and meant to be funny**).  My group's director comes into my office today and starts telling me this tale of getting a gift card for a family member.  Knowing Coldwater Creek is a former employer, he knew I'd have a special appreciation for this. 

He wanted the message on the gift card to simply say this:

Thought you might like some "retail therapy" after the holidays.

Simple enough.  When he got his receipt, it looked like this:



OK, most people who develop any web content realize that this content is HTML encoded.  "Normal" people would probably not care about the encoded quotation marks appearing as they did on the receipt, and perhaps attribute it to a glitch.  The fact that it's being encoded is a good thing to prevent possible script injection since the text is accepted over the web.  The fact that it's not being decoded is, of course, the bad thing. 

But it gets worse (or better, depending on your point of view).  Coldwater Creek adds a really nice touch to its gift cards during the holiday season: they hand write each gift card to add a personal touch.  You can probably guess where this is going, so let me cut to the chase and show you the nice, hand written card he received:



Beautiful, huh?  So instead of being a nice added touch, it's not very useful as a gift (though quite entertaining).  There's two things that come to mind with this.  The first is humor: somehow, this passed human evaluation.  The text doesn't make any sense at all, so as a personal touch it just doesn't work.  I don't expect everyone to understand character encoding or HTML encoding, and I'm sure people sometimes ask for obscure verbiage in their gift messages that won't always make sense to the casual observer.

The second (and sad) part that comes to mind is how process breaks down on development projects.   I recently read another article from Joel that addresses software development issues: 12 Steps to Better Code.  His article outlines not coding practices exactly, but rather environmental issues that result in better, more robust code.  If software projects are hurried, critical steps may be skipped or shortened, which often leads to improper analysis and scoping of a problem, may lack a test plan or regression test, etc.  Of course, even the best of environments won't yield bug-free code, but good software development is often related to architecture and construction, and it begins with a solid foundation.  Similar and not-so-funny issues plagued X-Box in Japan (no one took the time to do the right usability tests), Windows ME (just a bad release -- we all know it), and even the recent Diplomacy computer game (too bad, too, I was looking forward to this), to name a few.