Red Threads

This blog has moved! Please divert to http://www.cloudsoftcorp.com/category/red-threads/ for new developments.

Where, not What.

I interviewed a developer recently and given pause by one of his answers.  We'll call him Candidate J.  He was fresh out of school, just finished with his Masters, and very highly recommended.  I asked him how he would solve a coding problem; J's unabashed answer was to tell me what he would google.

Now it certainly wasn't the answer I was expecting, but I had to concede it was a right answer.  He could have just done the google in the background (this was a phone call) and told me the answer, but no.  For him, telling me where to find the answer is the answer.  And this isn't unique to him.  Microsoft suggest you can only decide something once you've bung it (binged it?).  URLs that are lovingly crafted to hint at their contents are out-twitted by bit.ly and tiny*.  Nobody remembers anyone's phone number (apart from one's own, sometimes), and long division is being forgotten.  But before I get lost in the snowdrifts of nostalgia let us stop.

I see a generational shift taking place.  It seems I'm now the old guard.  (I was warned that this would happen.)  The new guard has grown up with the ubiqui'net, calendars and facts and figuring and memory outsourced to an (almost) always-on cloud.  Pass-by-reference is replacing pass-by-value.  No value judgments here:  this has a plethora of advantages, provided of course that one is able to interpret the object being pointed to.  The sites that Google gives based on J's keywords were far more complete than he could give over the phone.  They they can evolve and be corrected even after the pointer is passed.  And in the case of the web, they provide a forum where folks can discuss it, explicitly on the site, or externally by referring to it.

The mismatch in this case is that I knew the answer; my intent in an interview was to establish whether Candidate J knew the answer.  With his pass by reference the question moved slightly to whether he could understand the referents--which happily a few more questions confirmed that he could.

There are interesting analogues in computing.  Take the key principle of SOA, for instance:  instead of loading a library everywhere a function is needed, call to a service.  Or MDM:  rather than keeping one's own copy of data, get access to an official feed.  (Can you tell I've been sitting at the Gartner Architecture conference for two days?)  The same benefits apply (coverage and evolution), as do the challenges (comprehension).  And a huge industry has been built integrating software and schemas to solve the comprehension challenges.

Or take the cloud:  when I deploy to a platform such as AppCloud or AppEngine or force.com, I don't know the details about what I'm deploying to, and I don't need to.  I don't need to know what the stack is or how to build and manage it because I know where it can be done for me.  But I do have to know how to evaluate and consume these platforms, comprehend what they do, decide whether the reliability/cost/security/jurisdiction is good enough, and finally deploy in some manageable way.

Recognising the Cloud being young, we have the opportunity to simplify the where question, with standards around the APIs and metadata.  For Monterey, the jclouds project has been a big help, giving us access to dozens of cloud providers at one fell swoop.  There was just one piece missing.  I can surrender my requirement for detailed knowledge of "what", but some understanding around "where" is still important.  Monterey optimizes the location of stateful processing, and to do this it needs two ingredients:  it needs to know what dimensions constitute optimality (latency, cost, compliance), and it needs to know the locations of the clouds it uses.  For the past 18 months, we have been using (and refining) our own location metadata schema for cloud.  But ideally this belongs as part of the cloud ecosystem, not in the Monterey umbrella.  An open-source provisioning system is its natural home.  jclouds agrees.  To my delight, over the course of the past and coming months, Cloudsoft will be open-sourcing and supporting their location metadata as part of the jclouds project.

So things are changing.  It's an exciting time.  As for what happened to the candidate...  Reader, we hired him.  J has been a great addition to our team.  Although there was one situation that this where-not-what mindset backfired:  on a long train journey from London to Scotland, he claimed he couldn't get any work done--the Wi-Fi was down. 

Off the Ground ("don't read")

We have lift-off!  Cloudsoft is up and running, and its co-founder and CTO is now entering the blogosphere.  But at the same time that I'm starting to write...

I've decided not to teach my children to read.  I love books, and of course I want them to do the same, but a friend posed a theory that for better or worse has changed how we're raising our kids.  Until this week, I've been diligently teaching Lucas the alphabet:  but no more.  Apparently learning to read when you're very young screws you up.  Well then, I'm a lost cause, but we needn't go out of our way to pass on the sins of the father.  Apparently, among other deficits, it can cause poor memory.  At least I think that's what my friend said...  My own memory is appalling (though having outsourced that functionality to 3G technology -- grep, google, and the good woman -- I get by).  But until this week I hadn't realized that Doctor Seuss was to blame.

We'll screw up our kids whatever we do; this theory was compelling.  Language is wonderful, certainly, yet it's a skill that is mostly aural and oral (for most people, possibly excluding bloggers and their Dear Readers).  Lucas loves his stories, devouring the pictures and hanging on every word.  Why force his eyes towards the letters?  For it might dampen his joy; and it will surely distract from the story, which is infinitely more important than the letters which constitute it.  There is a semiotic gap between our signs (words) and the signified (concepts).  There is a solipsistic gap between our concepts (categories) and the reality (instances).  These levels are necessary, for both thought (cognition) and language (communication), but can they be developed in one modality -- the spoken word -- for now, while the eyes be left to focus on images?  For it is more important that a child know how to listen to stories, than that he know how to read the words.

Surprisingly I've not been able to find much research in the area, but two principles stand out.  Firstly, children seem to learn multiple languages quite well if and only if each has a dedicated context (e.g. Mum speaks French, Daddy English, and German at school, as with my cousins; or in my children's unfortunate case, Mum speaks rough Glaswegian, Daddy coarse American, and a gentle Borders Scots accent on the playground).  It's tenuous, but maybe the modalities argument works.  Secondly, and more compelling (but less conclusive), kids who learn to read early don't seem to do any better than their counterparts who learn when they get to school.  So by Hippocrates, or even Blaise Pascal, we should not be stressing reading, not just now.  Instead, let us be creativite and attentive, tell stories and draw pictures.

Returning to the good ship Cloudsoft, we're charged with developing a complicated piece of software.  I've suggested we not do any coding for a wee while, and the team has agreed -- for reasons similar to those above.  Coding is a mindset, of letters and symbols with a precise and elegant semantics, similar to reading.  And it is similarly addictive, as knows anyone who has written several hundred lines then realised (or got told by a buddy or code reviewer) that it's all wrong.  And it is similarly restrictive, for when enmeshed in code it can be hard to step back and think through what's the best design.  A good software design plan makes the code smaller, quicker to write, and crucially, much easier to maintain over time.  Simplicity.  It's worth devoting time to -- not too much, for the design will be spent and jettisoned, and the proof of the pudding is in the execution -- but enough to get us from lift-off into orbit.  The team is unanimous, and it's design time aboard Cloudsoft:  we too will be telling stories and drawing pictures.