Eric Leach's Weblog
Today's lesson: Bike 2.0 presages Web 2.0
About ten years ago, I built my first bike from the ground up. I selected a cool Kona frame that I liked and ordered it through our distributor. One of the reasons I chose the frame I did was because I wanted a single speed bike. No gears, 10 speed cassettes, derailleurs, shifters - in short, way less moving parts.
I picked out wheels, fork, stem, saddle, brakes - and everything else I needed to complete the bike. When the frame arrived, I slipped the seatopst in and put the frame up in the stand, "chased and faced" it, threaded in the bottom bracket, bolted on the cranks, and spun 'em hard. It already looked like a bike.
Building it went faster than I expected. I bolted the front and rear brakes onto the mounts, pressed in the headset, cut and filed the fork's stearer tube to fit, bolted on stem and handle bars and mounted the brake levers. About a half hour later I snapped the pin back into the chain, pulled the rear wheel tight and cranked down on the rear skewer, tightened the pedals onto the cranks and hefted the biked down out of the work stand. The whole process, from box to bike, took about an hour. Bike 2.0.
That bike road great, that first time and just about every time after that, too. I built a bunch of other bikes after that, but none of them as easily or as fast.
So, to the lesson. Simple technology is better.
Lighter, easier things attract more people and get used longer than heavy, complex things. They break less. When they do break it's easier to fix them. Less moving parts. It is so tempting to want the bells and whistles, all the functionality and the latest cool gadgets. It is so tempting to want to solve the whole problem with one big package of things.
If you look around the software world now, you can see a definite trend toward using simpler, lighter weight technologies. I think this is what most people are referring to when they bandy about the term "Web 2.0", which I had begun to believe was simply a marketing buzzword, sort of like "scalable", "interoperable", "out-of-the-box", and (my personal favorite) "performant". I was very wrong.
Yesterday at Java One, I went to a session on JRuby, which began with a demonstration of how much less code is required when building something with Ruby than with, say, Java. Now, I don't write code, but even I could see the advantages of using less stuff to do simple, commonplace tasks. Sure, you give up some functionality, but at what cost?
It's actually the same with bikes - most people think they want ump-teen gears, even if they only use a few. When they bring in their 20-something speed mountain bikes for maintenance, they've usually managed to use the heck out of only about 4 or 5 of those gears. When you scrape through the gunk, most of the cogs and chainring teeth are relatively untouched, but a small few are ground down to sharp points. I think the same principal holds with software - that rarified breed of software which actually manages to get deployed in the first place rarely uses more than a small subset of its intended functionality.
There is another force at work here - utility (another marketing co-opted word), which is what you achieve when you put functionality where it is needed, when it is needed. Why leave simple stuff on the server when you can put it on the client? The web is becoming a place ripe with interactive, 3-D experiences, a place of visually compelling and artfully crafted user interactions. Some of this has to do with attracting an increasingly jaded and difficult to please online community. But some of it is there because new technologies have made tricky things simpler to create and, perhaps most importantly, made it possible to distribute workloads and functionality in new ways without breaking important stuff or creating needless complexity.
You can tell people are fed up with complex things because they will pay hundreds for a 60GB hardrive with a shiny white shell and a click wheel and a 1" color screen and which they happily fill up with songs using what might be the world's least functional "digital jukebox".
I will probably eat these words, but it seems harder to write crappy code, and subsequently applications that break, using things like Ruby, Ajax, Dojo, and the like. Software applications will gradually get simpler, easier to maintain- more fun to write, more fun to use. I know I spent far less time tinkering with that single speed than with any other bike I owned. I miss that bike...
Posted at 09:16PM May 18, 2006 by carlericleach in Identity | Comments[1]
Reputation: My opninion of the general opinion...
I pray thee -- and I'll pay thee bounteously --
Conceal me what I am, and be my aid
For such disguise as haply shall become
The form of my intent.
Viola, Act 1 Scene 2, Twelfth Night
I've been thinking about reputation a lot recently, particularly after reading something in Dave Kearns'
I love bold, passionate statements such as these as much as the next guy, don't get me wrong. And I think reputation is a useful way to qualitatively measure the efficacy of a given individual's identity in a particular context, especially on blogs and in other (relatively) non-sensitive online environments like social networking. But to suggest reputation will replace trust just didn't make sense to me.
I think it says something that reputation and mistaken identities are the basis of our great comedies. And I suppose that is what led me to Viola, who pays well to have her reputation established as Cesario - and hoo boy what folly ensues. I could have just as easily settled on Jack Lemmon in Some Like it Hot, or Tom Hanks in Bosom Buddies, but Shakespeare is always a useful fallback device when trying to make a point (lernt that in skool).
Reputation is spontaneously bestowed and functions well in dynamic, interactive environments. I get that. Communities bestow reputation - and in some situations that is radically more valuable than having some measurement of an idividual's identity dictated. I get that too. But reputation is often unreliable, as we've seen, and I think there are certain situations when trust - based on strongly identifying systems - are the only way to have a safe interaction, especially when the outcome of that interaction potentially puts people at risk or in danger.
Is reputation always enough, even in dynamic and loosely defined situations? What about when a group of young men show up at a disaster site wearing fatigues bearing the insignia of a National Guard unit? Based on the reputation associated with the National Guard, those young men might be granted access to communications systems, be granted the privilege of distributing food and water, and be provided with the means to preserve order and the rule of law.
I would love to believe that reputation is enough to establish those rights and provileges for those young men, but I cannot. Blame it on my liberal arts education. Call it cynicism. Call it what you will, but I need more. (I suspect FEMA does, too.)
Perhaps the statement that reputation will replace trust ought to be conditionally applied here, perhaps limited to situations where favors and obligations, trust by association, and similar forms of social currencies are acceptable.
I'd prefer to see a discussion where reputation and trust are considered complementary parts of a system that can reliably ascertain and interpret identity.
Posted at 11:56AM Apr 23, 2006 by carlericleach in Identity | Comments[0]