But what many software developers know so well in terms of their code is forgotten on the humans that ultimately use their applications.

Take the recent news about the upcoming iPhone 3.0 update and Google’s Latitude location system.  It allows you to see where your friends are on a Google map, and by many accounts, the code is beautiful.  But beyond the obvious feature of seeing where other people are at any given time, what is the object model behind the use?  What will real people use this feature for…and when?

Timing is one of the essential frameworks behind object oriented programming.  An application needs to know what triggers a certain event, when, and in what context.

So regarding Latitude, I ask:  What triggers my need to see where other people who I may or may not know are?  What prompts me to broadcast my position for others to see?  And what prompts me reliably to turn off this function when I want privacy (assuming I’m not someone oblivious to living in a privacy-free environment)?

An engineer’s answer may be, “Well, we give you all this granular functionality to decide who sees where you are and when.”  But in my view this ignores the human context in a day-to-day setting, where one is overwhelmed by a constant stream of messages and tasks which we must perform to maintain any number of other objects spinning in our lives.  We feel often as though we work for our machines, rather than the other way around.

Loopt is a similar application to Latitude, and my friends and I – mainly early-adopter tech geeks – tried frequently to use the app to find each other.  It was fun…once or twice.  But without an event in my life that prompts, “Use Loopt (or Latitude) now or you can’t do something you really need to do,” these apps are like a gun without a trigger. And they join the long list of untouched icons on the back pages of my iPhone.

Software developers need to remember that the object model doesn’t end with the code.

Stay tuned for the green transportation application UpStart is building.  I hope you’ll agree that we take this object lesson seriously.

Leaking intentions privately to individual advisors or small cadres like one’s consultants or Board can sometimes be more dangerous than sharing them openly.  Executive Board members are notoriously loose-lipped within their personal networks.  It is partly what one looks for in a Board member.  On one hand, we want them to keep our secrets.  On the other, we want them to tell people they trust about what we want to do.  But the problem with this is three-fold.  First, this limits the set of intentions only to those where senior executives are champions or advocates, and Harvard’s Clayton Christensen has well argued that this set of intentions is inevitably watered down from sources toward the middle and bottom of the org chart.   Second, if the Board member errs and confides privately in someone who then uses the information to move against you, you may never know until it is too late.  Third, if only a small cadre know that the intention is yours, then if someone else appropriates the information and makes a move in the market first, the public will generally believe that it was their idea, not yours.

A lot of people knowing your intentions can be a better move.  I made the point earlier that if Steve Jobs had intended, he could have taken the general idea of PostScript from Adobe and made his own independent solution without them.  But he didn’t.  Did Adobe’s Warnock and Geschke just get lucky?  Not exactly.  By the time Steve Jobs met with Adobe there was a large community in the Bay Area who mutually knew and supported both Steve and the Adobe team.  As the record of email between Bay Area computer enthusiasts at the time has shown, many people in the community knew generally what Adobe’s intentions were.  Making off with their ideas would have had negative consequences in the community of support that Jobs now relied upon.  Even if he had decided after seeing Adobe’s technology that the right strategy for Apple was to appropriate it or re-invent it on his own, he would have had to find a way to make good for Warnock and Geschke.

The community of trust, not Adobe’s intellectual property, helped ensure fair play.  In the end, Jobs not only collaborated with Adobe, he bought 5% of the company as part of a partnership deal that gave the budding firm a strategic leg-up and improved its appearance for future financing rounds.  Perhaps Silicon Valley should be seen not simply as a venture capital led knowledge-brokering network as some have suggested, but rather as a community that uses social consequences to impose constraints on what people do with information that is openly shared.  In this view, venture capitalists are not just knowledge-brokers.  They are more importantly a key arbiter of fair use.  If your company is funded (or seeks funding) by any member of the tight-knit VC community and you use others’ knowledge in a way that the greater community feels is inappropriate, you are likely angering people whose VCs know your VCs.  For this to work, though, the greater community must know what your intentions are – or at least the rumor mill must be circulating them.  No wonder so many hybrid business models from eBay to Google come out of Silicon Valley and choose to suffer the incredible cost of maintaining headquarters there.

Click here for the Previous Entry.

[Click here for Entry #14.]