Hats and headspace

The mobile-friendly application that I hope to be dog-fooding by the end of the summer has three main components:

1. The bits that you actually see and tap and swipe on the phone itself
2. The database that not only contains all the data, but also does a lot of the heavy lifting, logic- and security-wise
3. A relatively lightweight web interface that more or less acts as a traffic cop for bytes flowing between the mobile phone and the database

It's no secret that I'm more comfortable working in parts #2 and #3.   Normally, what we coding primates call "front-end development" I try to do with people who are blessed with an eye for layout, aesthetics, an appreciation of minimalism, and a blissful ignorance of what goes on behind the curtain.

(Normally, I don't champion ignorance...unless it's of the cultural graffiti that each celebrity leaves in their fifteen minutes.  But in software development, it can actually be an asset.  Whenever possible, I try to give myself a few days' distance from code before I demo. it to a client or user.   That's time enough to start to forget about the intricacies of what's going on under the proverbial hood.  It's like taking a car out for a test spin, really--anyone but a mechanic should rightly give more attention to the steering wheel than the spark plugs.)

This time, however, I don't have the luxury of a front-end developer.  Partly because I'm trying to do Version 1 on a tight budget.  But also because I'm using this project as an excuse to learn the Cordova platform.  (Aside to non-developers:  If you don't know what Cordova is, don't worry about it.)  The shiny new platform aside, my natural inclination would be to leave front-end until last.  It's simply not my strength, after all. 

But the problem with doing the "middleware"--the web API ("Application Programming Interface")--next is that, of the three layers, it's the least in touch with reality.  The database has to be done first:  It defines the shape of the information--what's related to what else and how.  That's real.  Equally real are the buttons and text and fields that allow the user to control their data and how it's presented/manipulated.

The web interface?  Not so real.  I mean, yes, it still does important things like making sure that each user is properly logged in before s/he is allowed to look at, much less touch any data.  And while the database contains the bulk of the machinery required to read, update, and delete data, something has to pull the levers and flip the switches.  Also, however much sanity-checking and error-handling is done w/in the database, it would be downright irresponsible not to build any filtering into the API as the proverbial first line of defence.

In normal operation, the front end logic and the back-end logic would evolve in tandem and symbiosis.  But I've found that having to wear all three hats does something different to the head beneath them--at least in this instance.  I think I already have a healthy respect for the user interface folks; doubtless this foray outside my comfort zone will only increase that.  More to the point, I'm hoping for an even bigger bump in empathy for that forgetful, easily distracted creature of habit typically known as "the user."