Appropriate ness (part deux)

I recently did a design review where there was an issue surrounding their choice of 'data storage implementation'. I use quotes because to me as a web developer, any data belongs in a database.

The issue arose over the fact that for this application written for the Java environment, they didn't need to store anything but usernames and passwords. They planned on using JDBC and having just one users table.

Like I said -- all well and good by me. I'm more used to having more tables and more relations between my data, but again it seemed most natural to me.

The surprise came when someone suggested that they just use a plain text file. If they were only going to store limited amounts of data and very very limited associations, why not just plain text?

Maybe this seems obvious to those who have had this experience before (or more than once), but it seemed so obvious to me that it was obscured. After the fact, it was indeed the right choice. Case to point: 1) Java has built in I/O operations 2) Their I/O operations would not (conceivably) cause any buildup and (most importantly) 3) JDBC is yet another thing to implement and (potentially) cause errors in their system.

Call me crazy but that Occam's Razor is either a natural talent or a life-long quest. For me it seems the latter.

So here's to other people's insightful (yet sometimes humiliating) comments that make our lives that much less complicated.

Appropriate ness (Appropriation?)

I recently did a constraint-satisfaction problem (CSP) in LISP to solve sudoku puzzles. I finally was able to visualize the recursive pattern and (to me) it looked alot like the stock market circa 1998-2005 -- up-down-up-down-down-up-up-down-down-down-down-up-up-down-up-up...

This actually reminded me of Matt Zandstra's book PHP 5 Objects, Patterns, and Practice. I read this at a time in my life where I had (naively) written an architecture for a system (in PHP5) which was quickly becoming unmanageable. This book helped me collect my thoughts about how to re-collect my code.

One of the things that I found very interesting which had never blipped on my radar was the idea of the appropriate throwing, catching, handling, and re-throwing of exceptions. Matt Zandstra emphasized that exceptions are powerful error-recovery tools -- but that they need to be handled at the appropriate level in your application: that model-level exceptions must be caught and handled (hopefully recovered) in the model and -- only when necessary -- passed controller. Heaven forbid if they propagate to the view.

Chris Snyder's book Essential PHP Security chimes in with the idea that often errors which occur at lower levels can cause security breaches. How many sites have you visited that have said "Cannot select `id` from table `users` with value ....". So if i just tweak this input-field...

So think about exceptions and their course through your application -- are there some which are relevant only to the model? Or are some worthy of propagating all the way up to your controller? Who owns that exception? Where does the buck stop?

User Expectations (part deux)

It's strange how the current generation (don't get me started on the following generation) has become accustomed to certain expectations for software. CTRL-C should *always* mean "I want to take whatever is selected, and use it somewhere else." Menu -> File should *always* contain "Save as..." so I can take what I've written and save it as a different version. (speaking of which -- when will Operating Systems start implementing integrated version control?)

For those of this generation who have used any version of a search engine well enough to know how to "manipulate" it (i.e., correctly use it) to find relevant results, we know that "-" (the minus sign) means "please, don't include this word in my search results".

I am not a frequent ebay user, but it delightfully participated in my "reality" by accepting that "-airsoft" as a search parameter meant I wasn't searching for an airsoft gun.

For better or for worse, users have already set standards for how our programs should function. To go against these "traditions" is to go against any other established societal standard -- to drive in the left lane; to turn a screw to the left in order to tighten it; to have the "power" button on the right-hand side of the TV remote-control; to defy gravity...

As any good citizen of the human population, our job is to question tradition; however, some traditions are so ingrained and so untouchable that we must acquiesce to the norms and toe the line.

When designing user interfaces, first ask yourself -- "would this be most natural to me?" As any HCI professor would tell you, that's not enough. You must think outside your own inclinations and actually consider the input of those who are not accustomed to thinking "behind the scenes" of an application -- who can actually (I might say "without bias") say "ladies and gentleman of the jury -- this. does. not. make. sense..

I wish that you would just leave
Because your presence still lingers here
And it won't leave me alone
These wounds won't seem to heal
This pain is just too real
There's just too much that time cannot erase
-- Evanescence - My Immortal

User Expectations

I put in my dollar bill, my quarter, my nickel, and my dime (notice that decreasing size dominates decreasing value). I pressed the "Mr. Pibb" button. And what happened?

Out came a Cherry Coke.

Strangely enough, I didn't really mind. I may not especially like Cherry Coke, but it suited me just fine: it had sugar and caffeine and that oh-so-great bitter-sweet cola taste.

My confusing experience at the vending machine is analogous to what users may feel while experiencing our applications. In my case, the supplier incorrectly loaded that particular slot; or, perhaps, loaded it correctly but didn't bother to change the label. Both cases pretty much sum up what we as coders are prone to do -- either not detect or not care about interface discrepancies.

Users can find these "mystery boxes" to be annoying, especially if they eclipse major functionality of the program. For instance, when no soda comes out at all after I've inserted my money and pressed a button -- well, I guess that's what Customer Service numbers are for...

What's bizarre to me is that I have heard of cases where a QA Engineer has discovered and fixed a "bug", only to cause Customer Service to become inundated with complaints regarding the missing "feature".

It shouldn't be so much of a stretch to imagine someone who uses who is used to pressing Mr. Pibb in order to get a Cherry Coke. But they've learned: either through their own mistakes or through someone else's -- that kind of knowledge is acquired, not explicit. Either way, money has been spent without total satisfaction.

Do you think that person would be annoyed if, unexpectedly and unannounced, a Mr. Pibb started coming out when they pressed Mr. Pibb?

Embrace your mistakes. Bugs *can* be features. If you still feel that serving up ice-cold Mr. Pibb is worth your while, make sure that it is clearly labeled, fully stocked, and that those who came for Cherry Coke can still get Cherry Coke.

From this time, unchained
We're all looking at a different picture
Thru this new frame of mind
A thousand flowers could bloom
Move over, and give us some room
-- Portishead, Glory Box

Priests in the Religion of Technology

If I had a dime for every time someone asked me "So, what's your major?" and I replied "Computer Science" and they replied "Oh...", and switched subjects...

Now, believe me when I say that I know we are nothing special. We are simply more familiar with a subset of today's technologies. I repeat, we are nothing special. No, really, they hate us.

I laughed at, yet was so humbled by, It Ought To Be Simple's post I'm An Idiot... (And Other Lessions From The IT Department). It seems we have a reputation with our friends and co-workers -- and not the good kind.

Yet you can't help but feel that we are part of a religion centered around technology... That we are the physical 'hands' of some super-natural being (i.e., beyond many people's understanding or interest) that affects the daily lives of millions of people.

Though it seems that the electronic deity we represent will be around for some time longer, some people are not so glad about it. Maybe they just need to meditate with their crackberries or plug in their earbuds and take control of their environment.

We are building a religion
We are making a brand
We're the only ones to turn to
When your castles turn to sand
-- CAKE - Comfort Eagle

(btw, Asimov expressed technology as a religion back in the 50's in his Foundation Series. And to think -- they had just developed Fortran...)

Hobbies Are Work, Too

I have friends who are musicians. To me, that always seemed like the most awesome hobby slash career in the world. I was very surprised to hear that, though they love making music, sometimes it can feel like a chore -- specifically, getting started on a track. When you have the concept for a song in your head that's been brewing for a while, you don't want to go back and start from the beginning -- to go through the necessary process of transferring it all from your head to a 'physical' medium. You just want what's in your head to magically exist, and go from there.

If you're like me, you have a lot of ideas swimming around in your head. Yet even though you are excited and have so many great ideas for extention, you never seem to get started -- there's some sort of mental block keeping you from saying "let's roll".

The fact is, anything and everything is work; because nothing is free. But sometimes things are worth their price tag.

Whether you're making music or a website, your outlook on the project is expressed through your coding. We are, after all, priests in the religion of technology. As Khoi Vinh says in 37signals' Getting Real, It Shouldn't be a Chore:

Enthusiasm manifests itself readily of course, but indifference is equally indelible.

So be positive. Start your next project with gusto. Because it's all about your relationship with your medium.

When you write a book, you need to have more than an interesting story. You need to have a desire to tell the story. You need to be personally invested in some way. If you're going to live with something for two years, three years, the rest of your life, you need to care about it.
-- Malcolm Gladwell