“I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone.” — Tom DeMarco

Phew, I know I’m relieved.  Sure as shit, programming never did seem like engineering to me, the last 20 years I’ve been doing it.  Good thing we don’t have to carry on that charade.

We’re left with one other extreme view, that “programming is art.”  But I don’t think many folks want to see source code hanging in galleries.  Even the pinko commie FSF leader agrees, and he’s right because he’s an Emacs guy:

“I would describe programming as a craft, which is a kind of art, but not a fine art. Craft means making useful objects with perhaps decorative touches. Fine art means making things purely for their beauty.” –Richard Stallman

So, let’s split the difference and neatly pigeon-hole the practice of programming as a “craft”.  Seems fair enough.  Pete McBreen points in this direction in his book Software Craftsmanship.  Knuth was thinking along these lines back in 1974, too.  But using the analogy of “craft” doesn’t go very far to predicting programmer aptitude.  Unlike most other crafts (smithing, knitting, ceramics, architecture, furniture, you name it), programming exists in a realm of nearly pure abstraction, doused liberally with a tonic of interpersonal communication and collaboration.  An odd mix.

So how do you pick out the good geeks in a crowd?  Malcolm Gladwell writes about the difficulties, and I think there are strong parallels between finding good QBs, and finding good programmers.  Until you just try them out, you can’t really know.

Since I’ve long viewed the practice of programming as a craft, I’ve tried to apply the notion of a portfolio, a gimmick I learned from my boss back at AOL.  A good programmer should have a body of work, which can be shown, and in it you will find strong clues as to the type of programmer they are.  So unless I’ve worked with someone before, directly, along with references and resumes, I ask them to provide:

A significant code sample which you feel is representative of your best recent work.

You might be surprised how that surprises folks.  I’m not sure if they think I’m going to poach their code, or rat them out to the employers whom they were working for when they wrote it, or what.  In any case, of those that get over it and send me something, a disheartening number send me what amount to toys – 100 line incomplete snippets of something-or-other.  Or, just as bad, a swath of user interface callback code, or a class definition that’s 90% setters and getters.  Sigh.

Once I’ve settled on the notion that a particular person might be a good hire, I try them out.  That amounts to a six-month “no fault divorce” period, where the candidate is brought on board as a 1099 contractor, but in all other ways as a full fledged member of the team.  Most folks need six months to settle in, get embedded in team dynamics, and learn enough of the problem domain to be useful.  During that time, if anything doesn’t feel right – and I do this purely based on gut instincts – I gently end the relationship.

It doesn’t always work, but it works well enough.  Sometimes it makes me wish that there were true apprenticeships in programming, Programming Guilds whose members (graduates) would come as known quantities, merely through the imprimatur of their Guild Master.  Meantime, we do what we can.

Take this simple advice to start writing better:  Stop using the verb ‘to be’.  If you’re like me, it’ll take you awhile to get the hang of it.  Even today I lapse back into using ‘is’ from time to time, but whenever I put myself in the frame of caring about what I write, the practice returns readily enough.  It couldn’t save the novel I wrote from being a “learning experience”, but at least my prose packs a little punch.

Try it.  If it doesn’t blow your mind, at least your sentences will sparkle.

Stakeholder: “We need to fix sort order.  Let’s make sure that results we can’t show an image for are deprioritized.”

Developer: “Can do.”

Time passes.  Software is written.  Then:

Developer: “I’m finished.  The results without photos are at the end of the list.”

Stakeholder: “I don’t understand.  Why are they showing at the end of the list?  Shouldn’t they be in their usual places in the list, but greyed out, like we talked about?”

Gadzooks, we’ve fallen into that trap… AGAIN!  It’s the mother lode of assumptions:

When we agree to something, that something we’ve agreed to is the same thing for you as it is for me.

“One good analogy is worth three hours discussion.”

– James T Mccay

The problem of creating a shared concept crops up all over software development, from requirements, through testing, implementation, documentation, and on out the door into the hands (and minds) of users.  The problem pops up between stakeholders and developers, developer and other developers, between accounting and customer support and users themselves.  It’s stamped all over everything.

I won’t delve too deeply into the metaphysics of this problem, but trust me, just below the surface seethes a pit of linguistics, semiotics, ontology, questions about quantum mechanics, psychology and the nature of the mind.  Nifty stuff, if you’re philosophically inclined.

“An idea is a feat of association, and the height of it is a good metaphor.”

– Robert Frost

I’ll try to stick to the more pragmatic concerns, here, and start with the notion of a mental model.  Without thinking hard about it, make a note of the very first thing you think of when you read this word:  Apple.

Ok, which was it?  A red fruit?  The computer company?  A particular computer, perhaps the one you’re using right now?  Or was it a particular apple, the one you shared on the grade school steps after school was over with that blonde girl that you had a crush on?

You have a notion of what “apple” means.  I might have a different notion.  That notion – the set of associations, memories, ideas, and so on, we call a mental model.  It’s mental because it’s in your head, and it’s a model because it isn’t the thing itself.  So, it’s a mental construct, a mind-thing that represents some slice of the “real world”.  Without even being aware of it, we construct and use mental models all the time, to help us function in the world.  They provide us with information about how something in the world will behave.  What we can expect as we interact with it.  They’re mind tools that help us understand phenomena, make inferences, and experience events by proxy.

You might view a mental model as a graph.  I imagine it as a web of connections between some notion and a set of associated notions.  For me, apple connects to “fruit”, “red”, “an apple a day”, etc.  Apple also connects to experiences, memories, emotions, and so on.  Some of those connections are strong and some aren’t so strong.  I label this graph as the “apple” graph – my mental model of “apple”.

“The world is emblematic. Parts of speech are metaphors because the whole of nature is a metaphor of the human mind.”

–Ralph Waldo Emerson

I won’t delve too much into why our mental models differ (my “apple” isn’t the same as yours) in the first place.  Instead, I’m intrigued by the problem of how to get the models running around in different people’s heads to refer more-or-less to the same thing.  One cause of that problem is that mental models they’re transmitted across a very lossy medium – human expression via language, be it visual, spoken, etc.

Here’s where meaning comes in.  When I tell you about “apple”, I am trying to move a copy of the “apple” in my head into yours.  I do that by trying to create the same set of connections in my head into yours.  I do this by trying to convey connections between my “apple” and your “apple” by relating my “apple” and its associations to your “apple” and your associations.  That act of linking bits of experiences and thoughts and sensations and emotions (ie., models) to one another is called meaning.  When I say, “This is apple: …”, I am trying to upload a small piece of my internal representation of the universe into your mind.

Meaning is heavy stuff.  And, as it turns out, difficult to transmit using language.  Why?  Because language (words) sits one level of indirection away from the models themselves.  Follow me, here.

We have the thing itself.  We’ll stick with “apple”.  Out there, somewhere, is the apple we’re talking about.  Then, one level removed from that, are the sensory experiences associated with that apple.  (Level of indirection: 1).  Aggregated in your head is that sensory input, memories, associations, etc — the mental model of that apple.  (Indirection now 2.)  Then there is the word I slap onto that model – “apple”.  Note that the word represents the model, but isn’t the model itself.  (Indirection: 3.)  Phew.  We’re three hops from the damn piece of fruit, and just getting rolling…

Now I try to talk about the apple.  I use the word apple, and a bunch of other words that are intended to connect the dots – make the same associations for your version of “apple” as I have attached to mine.  Again, add a level of indirection.  (4.)  You aggregate into your “apple” model.  (5.)  You slap the word “apple” on that model.  (6.)

Yep.  That’s lossy.  Your copy of the “apple” model that I’ve tried to convey to you sits about 6 hops away from the thing itself.  Maybe more, I’m not sure.  And there are no checksums.

If you want to make meaning-making work for you, use this tool called storytelling.

The art of transmitting mental models – of creating meaning – is storytelling.  Narrative, if you prefer.  Storytelling is the best practices way of moving a mental model from my head into yours, because it leverages biologically and culturally preset and reinforced mental models.  Stories have a well-known structure (think of XML).  They have conventions of characters and plot.  (Think REST HTTP verbs).  They are easy to persist, which makes them effective at moving mental models.

Which brings us to metaphor.  Compress a story down to its smallest, most compact and elemental form, and you will produce a metaphor.

A metaphor is a zip’d story.  (And, yes, for those of you still paying attention, that last sentence was a metaphor itself, but probably only useful to geeks.)

“But the greatest thing by far is to have a command of metaphor. This alone cannot be imparted by another; it is the mark of genius, for to make good metaphors implies an eye for resemblances.”

– Aristotle

Which returns us to that pesky problem of “I thought you meant…”.  At our disposal lie a wide array of tools for creating shared mental models: whiteboard diagrams hung in shared spaces, mockups and wireframes, requirements docs, etc.  But if you want to be really effective, use stories and metaphors.  Be shameless in assigning names and personalities to the actors, systems, modules and machines.  Give them personalities.  Talk about what they know and like.  Get to know them as a group.

Then, invent a defining, central story.  A system metaphor captures the essence of the system in the most effective communication tool we have – the story.

“The system metaphor is a story that everyone – customers, programmers, and managers - can tell about how the system works.” 
– Kent Beck, Extreme Programming Explained, p. 179.

But if I had oodles of free time I’d do the following geeky things:

• Lisp.  Really learn it this time.  No.  Really.
• Smalltalk too.
• Build and install an active solar system and a solar hot water heater on my house.
• Do an iPhone app.  Yay, Objective-C!

What’s on your list?

Charlottesville Downtown Mall At Night

As CTO, I seem to be getting the recurring question, “Can you (hotelicopter) find the tech-savvy talent you need in Charlottesville?”  It’s a valid question.  Long gone are the days of Kesmai, EA, Mr. Goodbucks, and the beloved Value America.  These days, we have influx of spooks, a smattering of biotech companies, and in the IT/Internet world… a whole buncha nothin’.

Usually I give a good new / bad news kind of answer to this question.  I’ll run through the good part first so we can get to the juicy bad part.

The good news is that you can do alot more cool stuff with a whole lot fewer people than you used to.  And even though we’ll be quintupling the size of the tech staff at hotelicopter, in absolute numbers, it’s still a very small number of people.  Armed with the right package of cash compensation, equity, benefits, a really cool place to work, and seriously fun stuff to work on, I’m very confident we can find the team we want.

The bad news, though, is that once we’re done cherry picking the local talent, all that’s left will be tumbleweeds.  (And bookstores and coffee shops.)

I recently had it put to me that Charlottesville stands at a crossroads.  On the one side, the ‘Ville could evolve into the next Austin.  You know, the cool Austin: vibrant arts and music scene, burgeoning tech mecca, nifty atmosphere, lots of fusion restaurants.  Sounds pretty good to me.

Or… Our beloved city could turn into Aspen.  You know, frigid Aspen.  The Aspen where private jets land to deliver out of towners and transplants to their ostentatious homes, and everyone who actually works lives… somewhere else.  Somewhere cheaper.  Like Waynesboro, Nelson County, Greene and Orange.  Let’s face it, Charlottesville’s already looking alot more like Aspen than Austin.  We have a sharp housing gap (the current downturn in home prices not withstanding), a widening income gulf, and with each passing decade, a sharp decline in local industry… of any kind.  At the current pace we’ll be left with just fancy restaurants, coffee shops and riding tack boutiques.

Aspen… Great place if you can afford it.

Just to confuse things, the majority of our site - the importantest parts, anyway – are still written in PHP, on a code base now 2+ years old and about a decade behind the times.  (Can you say “monolithic”?  I knew you could!)

The place we’re aiming for is a highly decoupled (and scalable), cohesive set of services, joined through REST APIs and/or fully reused common business models.  We have multiple “applications” now, all operating on a couple of common databases.  We’ve officially run headlong into one of Ruby on Rails’ deficiencies: programming in the large.  We’re not interested in computer science-y solutions, only pragmatic ones.

I suspect as we muddle along we’ll develop a component-level (service level if you prefer) version of the Law of Demeter, which will drive us to make the right decisions for decoupling.  I’m not too worried about that.  However, we definitely have issues with reuse.  Currently the Ruby on Rails state of the art solution for reuse is the gem.  Which, let’s face it, is a pathetic solution.

We’ve begun rolling what we call our “common” system, composed of a set of models, migrations, configuration artifacts, etc., shared between applications, wedged carefully into the RoR framework, and superglued in.  It supports use standalone, outside of a RoR application environment (though definitely somewhat hobbled in that case), and allows application-specific specialization of common models.

I’m not sure it will be sufficient in the long run, but thus far it is supporting a large degree of reuse between three RoR apps and our PHP site.

Store.find(:all, :origin=>'100 Spear st, San Francisco, CA', :within=>10)

Partly this situation is a byproduct of having a tiny R&D team, and the ‘ole “10 pounds of shit in a 5 pound sack” problem.  With access to more resources, we could make progress on multiple fronts.  But, even if we had an army of developers, startup life throws optimization into a stark light.

Wait too long, and we piss off customers and hurt uptake.  Too soon, and we’ve missed out on implementing features that hurt uptake and also cause us to miss our window for strategic positioning.

As is often the case in the CTO’s role, if I get the answer right, no one will notice.  I’m reminded of the Tao Te Ching:

The Master doesn’t talk, he acts.
When his work is done,
the people say, “Amazing:
we did it, all by ourselves!”