Mashup Camp Concludes

Mashup Camp just concluded in the Computer History Museum.  A very nice, direct, simple mash-up -- PodBot -- won 'best mashup'; second prize went to the everyhing-you-ever-wanted-to-know-about-Chicago-crime-statistics mashup ChicagoCrime.org.  PodBot does just one simple thing but does it for data around the world; ChicagoCrime does lots of things for just one city and subject.  Also, PodBot is all about having fun and ChicagoCrime is about not getting killed.  Sort of a yin/yang thing.

The unconference itself was good.  A lot of good sessions conflicted, so I had some quandaries; but I think I made the best locally optimal choices possible.  No regrets.  The WiFi was good (better than most conferences with 250 people in a single room) but still not perfect.  But it wasn't too bad since there was little need for a backchannel.

Software Development's Evolution towards Product Design

Software Development's Evolution towards Product Design -- Danc Redmond writes a great article from the perspective of a product designer.  I agree with nearly everything he says, especially the need for small, unified, cross-functional teams.  A few minor caveats:

• Programming, done properly, is not a production activity that can easily be separated from product design.  If it could be, it's basically rote work that can and should be automated.  The non-rote work that programmers should focus on is all about figuring out how to hack the universe in order to deliver superior benefits to the customer.  Which is part and parcel of product design, which is why those small, cross-functional teams are so valuable.
  
• A big factor in game development and web design companies' successes was sheer volume and high competition.  There are plenty of terrible user experience in both camps (books have been written), but the industries have thus had a chance to learn from lots of successes and failures and iteratively improve. 
  
• Nit: The benefits summary is great -- 98% success vs. 18% success is a great statistic that can get business people to sit up and listen.  But y'know, this needs to be backed up with specific references to really pack the necessary punch.

In the past, most of the software industry has been busy creating dancing bears.  It's not how well the bear dances, but that it dances at all.  That is changing.  There will be some isolated refugia for internal corporate software, niche verticals, and bleeding-edge hardware interfaces where those clumsy dancers will survive and even thrive.  But the rest of the industry is going to start competing on more than bare functionality, and that will quickly shake out the companies which won't or can't adapt.

AOL and Dojo

Several engineers(*) at AOL had a very interesting meeting with the Dojo guys last week.  One of the results is the announcement that AOL is hosting the Dojo toolkit on our content distribution network.  The reason this is great is because the major barrier to adoption of DHTML/Ajax/etc UIs is, honestly, the download times for the Javascript code; you only pay this once but it's a major concern.  The CDN helps enormously with this since it does automatic compression, caching, intelligent routing, proper browser bug workarounds, etc.  If enough people adopt this, it would be a win for everyone (only the first application to require a library module pays anything, the rest get it for 'free').

I hope we'll be able to do some more interesting things and help contribute to Dojo as well.

(*) OK, technically I'm a manager, but they let me wear the engineer hat sometimes.

Another One on Tagging: Data on Folksonomies

This folksonomies article is good for the questions it raises, but alsofor the data it collects in one place -- lots of good statistics ondel.icio.us and flickr usage of tags in this paper:

Folksonomies: Tidying Up Tags?
"Thisarticle looks at what makes folksonomies work. The authors agree withthe premise that tags are no replacement for formal systems, but theysee this as being the core quality that makes folksonomy tagging souseful. The authors begin by looking at the issue of "sloppy tags", aproblem to which critics of folksonomies are keen to allude, and ask ifthere are ways the folksonomy community could offset such problems andcreate systems that are conducive to searching, sorting andclassifying. They then go on to question this "tidying up" approach andits underlying assumptions, highlighting issues surrounding removal oflow-quality, redundant or nonsense metadata, and the potential risks oftidying too neatly and thereby losing the very openness that has madefolksonomies so popular." Commentary by Marieke Guy and Emma Tonkin,UKOLN. [D-Lib Magazine]

(You gotta hand it to the old-school Digital Library people.)

Why Tag?

One of the questions that keeps coming up in discussions about taggingis whether private tagging is useful and if so, how?  Is publictagging really the important application to keep in mind and if so,why?  By private tagging, I mean someone applying tags but notsharing them with anyone -- so they're useful for personal organizationbut not for sharing with others.

Empirical evidence suggests that tagging is most useful when public andshared.  But why, exactly?  Caterina Fake, in a panel atSyndicate, noted that people on Flickr get to "ride free" on top ofcompulsive categorizers.  I think this is certainly part of it,and maybe tagging is good occupational therapy too, but I have a gutfeel there's more to the story.

My fifteen month old son is an inveterate tagger.  His tag cloud looks something like this at the moment (somewhat elided):

airplane água ana bird book bulldozer bus bye choo-choo-train dada dog down mama phone tractor truck up wow

...which I know because he tags things repeatedly and excitedly,especially when someone else is around.  And I think this is thekey point -- this is a natural behavior, and a social one.  (He'lltalk to himself, but it's really second best -- he wants to share hisview of the world with other people!)  And of course it'saccompanied by pointing -- the original hyperlink.

That's as far as I've gotten.  Fortunately, Rashmi Sinha, in A social analysis of tagging,does a great job of analyzing exactly how tagging facilitates socialinteractions.  Go read it.  Also, read her earlier cognitive analysis of tagging as well.  Both great forays into the "whys" of public tagging.

I think this all suggests that private tagging might be useful in thesame way that talking to yourself might be useful (yes, sometimes, butnot a primary use case).  More interesting is social-but-privatewhere you share with a limited number of people; this is more difficultto do well than either totally private or totally public; is itvaluable?  How?  When?

Platform standards and loose coupling

Recently people have been talking about organizational standards for web application platforms (like Linux/Apache/Tomcat for example, or ASP.net for another).  Personally, I'm a big fan of the "small pieces loosely joined" concept.  Smallpieces are exponentially easier to build, test, deploy, and upgrade. Loose coupling gives flexibility and risk mitigation -- components canfail or be replaced without major impacts to the entire structure.  Allof these things help us cope with schedule and product risks.  Thetechnical tradeoff is a performance (latency) hit; for webapplications, I think the industry has proven that this is usually agood tradeoff.

I guess I should be clear here that I'm interested optimizing for effectiveness, notefficiency.  By effectiveness I mean that speed of development, qualityof service, time to market, flexibility in the face of changingbusiness conditions, and ability to adapt in general are much moreimportant than overall number of lines of code produced or even averagefunction points per month.  That is, a function delivered next week isoften far more valuable than ten delivered six months from now.

To do this, you need to start with the organization: Architecture reflects the organization that produces it.  So, first you need to create an organization of loosely coupled small pieces,with a very few well chosen defining principles that let theorganization work effectively.

Each part of the organization should decide on things like the application server platform they should use individually.  They're the ones with the expertise, and if there really is a best answer for a given situation they should be looking for it.  On the other hand, if there's no clear answer and if there's a critical mass of experience with one platform, that one will end up being the default option.  Which is just what we want; there's no top-down control needed here.

So the only case where there's an actual need for top-down organizational platform standards is to get acritical mass of people doing the same thing, where the benefit accruesmostly because of the critical mass, not because of individual projectbenefits.  There's not much benefit to bulk orders of Apache/Tomcat, soif you're avoiding vendor lock-in the main reason to do thisis toenable interoperation.  But that can be accomplished by picking openstandards and protocols -- pick some basic, simple, straightforwardstandards, make sure that teams know about them and are applying themwhere appropriate, and they'll be able to talk together.  This is a risk mitigation strategy rather than an optimization strategy; in other words, you know you can always get something working with a known amount of effort using the loosely coupled strategy.  When you're tightly coupled to anything, this is no longer true -- you inherit its risks.  Tightly coupling an entire organization to an application server platform also creates a monoculture, making some things very efficient but also increasing the risk that you'll be less able to adapt to new environments.

Google + AOL

It's official:  Google invests  $1B for 5% of AOL.  Considering Google's market cap bounced up $2.2B on Friday when the serious rumors started, it seems like a bargain.  Also, I'm hoping we successfully negotiated for access to Google's cafeteria.