Only Skin Deep

December 29, 2006

The new year has me thinking about ye old Y2K bug, and I noticed just recently that we’ve gone back to displaying two digits in a lot of places now. It makes sense, especially in web development. Screen real-estate is still at a premium and in most cases prefixing years with “20″ doesn’t really give a user any more information. There are exceptions, of course, but most day-to-day applications deal with relatively contemporaneous data and the need to distinguish between 2006 and 1906 is pretty slim.

Of course we all _desperately_ hope the programmers are storing “2006″ in the database and not “06.”

In the four years or so around Y2K, this date formatting issue became a big deal. We’d write an application and store the long date — 1999 or 2001 — but only display the significant digits: ‘99, ‘01. And there’d usually be some project manager or client contact that’d have a tiny little aneurysm over that. “_Haven’t you heard of the Y2K bug?_” they’d shriek, and then we’d get to hear scare-stories of planes falling out of the sky or national power-grids failing. Then we’d sigh and change the presentation to show those pointless two digits.

To be fair, if an application did get through displaying only the significant digits, the support addresses would get kooks writing in to warn about the dangers of Y2K and fritzing power grids. Everyone’s an expert. But fortunately this now seems to have dropped off everyone’s radar.

Despite ten years (and eight months) in the industry, though, I’m still amazed at the extent to which people confuse the presentation layer — how a program looks — with what a program does. The Creating Passionate Users blog covers this in their entry “Don’t Make the Demo Look Done”:http://headrush.typepad.com/creating_passionate_users/2006/12/dont_make_the_d.html, where they explain that a detailed user-facing side tends to trick people into thinking all the remaining work has been done.

I can understand why; we’re used to most things being built from the inside out: first the foundation, then the frame, then the guts, then the façade. But software is often developed from the outside in: imagining how the application will be used, designing the interfaces to access the system that does the work, and then actually writing the workhorse code.

But it’s still very confusing for non-developers who tend to think of the interface as the _end_ of development, not the commencement. I actually think this confusion contributed to me losing a job[1] once, when I explained that requiring a fully functional mockup was more than a little silly. What started as “make some HTML pages to show what the product looks like” became “add some Javascript to make it look like it works” and then “why do all my changes go away when I reload the website?” When I explained that the program was a mockup for demonstration purposes and thus the application didn’t actually _do_ anything, my soon-to-be ex-employers demanded that the mockup be hooked up to a database. (They still insisted on calling it a mockup, too.)

fn1(sidenote). The end came when I followed that up with an explanation about how an application could not be both an off-the-shelf product and fully compatible with everyone’s existing business processes.) In the end, though, the job with the people Elf calls “the giant spiders” taught me _lot_ about programming very quickly: I had been hired as a graphic designer.

Programs don’t — shouldn’t, in fact — show you everything they are doing. The reason you write programs in many cases is to automate processes and reduce the amount of information a human has to process. Something that seems conceptually simple, or has a simple interface, can hide a significant amount of detail work that happens behind the scenes. Although you might think the interface represents the application, it’s not.

That’s worth keeping in mind.

Just because a program says it is doing one thing doesn’t mean it’s not doing another — something you should keep in mind when using untrusted applications like browser toolbars and electronic voting machines.

Just because a program *looks* like it has a control for what you need, that control might not actually suit your needs — or, in fact, work at all.

Just because something looks simple on the surface — or is simple to explain — doesn’t mean it is actually simple to program.

Beauty is only skin deep and much is hidden from the eyes of men. Remember that.

*Update:* Want a case study? “The Virtudyne Saga”:http://thedailywtf.com/forums/thread/109003.aspx.

Posted in Technology