Most of the software development I do is user-facing in some sense.  In other words, the guy I expect to be clicking the buttons and pounding the keyboard when my applications are running isn’t a technology professional, he’s a mortgage broker from Topeka, or something like that.  I’m developing software for my parents generation or at least that’s the way I like to think about it.  So I try to make my interfaces clean, my options minimal, and my help-text easy to understand.

I’ve been doing that for a long time; so long in fact, that it’s easy to forget that not everyone writes code that way.

Today I was mucking about with MSSQL and got results I didn’t expect from a Union.  The actual code involved several views and about two dozen columns so I’ll provide an abbreviated version here rather than hitting you over the head with the whole thing (as I did to my office’s resident database guru)

SELECT 'First' as First, 'Second' as Second
UNION
SELECT 'Second' as Second, 'First' as First

What I was expecting to get back from this query was a two row result with columns labeled “First” and “Second” with data like this:

First, Second
First, Second

What I got back was a two row result with columns labeled “First” and “Second” with data like this:

First, Second
Second, First

In other words, the second row, showed a value of “Second” in the row labeled “First” even though in the second select statement I’d clearly specified that the value of “Second” belonged to the row labeled “Second.”

What gives?

Well as it turns out, MSSQL is dealing with the position of columns in the Union statement rather than dealing with the names of those columns.  This annoyed me at first — surely it should be checking the names to make sure it got the values right — but then the difference in paradigm dawned on me.

See, MSSQL isn’t developing its code with the expectation that a mortgage broker from Topeka Kansas is going to be using it; they’re writing code for use by software developers and they expect their users to prize speed and efficiency over ease of use.  The database clearly could spend the time necessary to check, row by row, to see if the order has been changed up but doing that would slow down the query; instead, MSSQL assumes you know what you’re doing and gives you the results based on column order.

Yes, if you’ve gotten the datatypes wrong or the number of columns mis-match you’re going to get an error but the underlying assumption — that the target user audience would rather the product be a little less intuitive in order to make it faster — holds.

Now, I got results I didn’t expect because I expected MSSQL to put ease of use before efficiency and speed.  I was in good company in making that assumption — though in my case it wasn’t a reasonable one — many of the criticisms leveled at the software development industry boil down to a failure to deliver on the user’s expectation of an intuitive experience in lieu of providing all of the knobs and twiddly bits that a technology professional might crave.  Indeed, one of the major drivers of Apple’s success has been its ability to understand and meet the challenges of getting developers to design for regular people rather than for themselves.

So how best to solve this problem of divergent expectations?  There is no magic practice, nor any set of fixed methodologies that anyone can really recommend.  Almost by necessity anyone in a position to rationally set user interface requirements will, by virtue of their own technical proficiency, tend towards those more full-featured, performance oriented, complexity driven interfaces.  The best solution is simply awareness and discussion; if we realize that the culture of software development is akin to a group of F1 race-car drivers designing a Toyota Corolla we can start to view requirements in opposition to our more niggling proclivities rather than indulging in them.