I started off this morning with a partially composed blog post in mind owing to my reaction to a lengthy conversation I had yesterday (tweeted for reference). For whatever reason it took me all day to sit down to tackle it, but perhaps I needed the day to stew over it in the back of my mind.
The basic premise is this: cleverness is a huge asset when applied to constraint-based technological innovation and is probably the most necessary attribute that someone can bring to your organization today.
Only the truly clever will avoid unnecessary reinvention at all costs to the point that, to the lay observer, this individual may seem like a downright lazy corner-cutter. Instead, cleverness is a honed skill that takes time, dedication and above all, a commitment to cultivate an appreciation for not only doing the least amount of work possible, but also the ability to pick the least amount of work possible that will also afford the most leverage in actually solving the problem.
This is not trivial stuff either, and I’ll tell you why in a bit.
First, I’ll identify 37 Signals‘s Jason Fried and Flickr’s Cal Henderson as my inspiration for this line of thinking. Conversations with both of these guys has taught me a lot about the value of cleverness and its relevance in each their respective successes. These guys are ruthless; whenever I’m stuck hemming and hawing between potentialities, I always ask myself, man, if I pinged Jason or Cal right now and asked what I should do, what would he say?
Well, after doing just that countless times, I’m pretty confidant, especially after yesterday’s exchange, that I can now serve myself. I’ve started to use what I’ll call the law of minimal reinvention. Or, to contradict myself and invent something new, maybe I’ll call it the The Fried Henderson Law.
The Fried Henderson is an approach to problem solving rooted in erudition, experience and a love of World of Warcraft. The trick is in seeing the opportunity space clearly, adding the right constraints (as many as possible), and then avoiding reinvention at all costs. More often than not, it’s triangulating a solution: what’s the shortest distance between where we are now and getting to the pub afterwards to celebrate our success? Or, to put it into Fried Henderson terms, what’s the least amount of work that I can do to satisfactorily solve this problem so I can get back to World of Warcraft?
Well, clearly, if you’re going to not only get back to WoW but avoid additional interruptions, you’re going to need to document your work. And, if you’re writing your own documentation, as the 37 Signals guys do — constantly — you’ll quickly realize the benefit of creating small and simple isolated solutions that can be reused as components over and over again, playing along with Tantek’s Building Blocks model. Better yet, the most clever folks will resort to using existing applications and solutions built, maintained — and documented — by others, and — provided the licensing rights check out — will use the solutions of other similarly clever folks over needlessly wasting effort reinventing a redundant solution.
Given the current state of the web, web services and the “mashup-cum-widget economy”, this is crucial and absolutely necessary to consider when hiring today. You don’t need someone who feels compelled to prove him or herself by reinventing yet another AJAX framework; the candidate who searches Google for an existing implementation with documentation is the one you hire. This is the candidate that you want, the one that is resourceful, can get things done typically under or near budget and with probably fewer resources and less time than an equally qualified but overly inventive individual. To make it catch-phrasey, you want someone who essentially subscribes to the Friend Henderson dictum.
So. For completeness I should point out that sometimes it’s okay to invent something again. Or to solve a problem in a novel or more effective way given changes in the environment, attitudes or opportunity space (broadband, reduced importance of privacy, launch of the iPhone, etc.). There are also a large number of uninvented solutions out there (namely the ones that haven’t been invented yet, in case my language yoo confooze) — for example, solving the cross-domain social networking problem (though some folks are working on it *ahem*). Or fixing drag and drop upload in the browser. Or getting people into the browser too. Etc etc.
The point isn’t to not be creative but instead to be clever, in a do-as-little-as-necessary way. There are so many great tools and technologies out there today with so little of their full potential discovered or exposed (I mean, had you thought of using Google Maps for viewing panoramas?! Neither had I!) that it’s silly to consider reinventing existing infrastructure when others have already done your work for you!
Do as Jon Hicks says and be a creative sponge for sure, but also following the rule of Fried-Henderson and be clever in what you endeavor to create! If someone has already bothered to create a better solution and to support it, for shuck’s sake, use it!
Factory Joe 
Makes beautiful sense to me. And the more you do it, the easier it gets. I’ve been slowly putting together libraries, processes, algorithms … but have never articulated the method as you have here. It’s exactly right.
Our dev team here is working with this philosophy in a slightly different way. Right now, we’re completely rebuilding an applicaiton from the ground up.
We’ve come up with an approach that will take a bit more time at the moment, but will free up plenty of time for WoW in the future. We’re essentially just building a shell for our software that will make it really simple to add features with minimal effort. Hopefully it helps give me time to get my Hunter to level 70.
Agreed. Though I don’t play WoW – I’ve always strived to avoid “reinventing the wheel”. I’ve been known to say “Don’t reinvent the wheel, make it roll smoother.” Definitely not something that will be on the cover of a book – but the fact remains.
I was wondering, about the documentation aspect. I used to keep a personal wiki. Call it, a personal knowledge base. I wish I could keep up with it, but – it only benefitted me. Any thoughts as to where this documentation should reside? If we’re not talking about a specific project doc, but rather just “information” that we gather through our lives – should we document these things? Where should those documents go? Public?
Colin, that’s an interesting point. I know many people who actually keep public personal wikis — describing ideas, thoughts, and to do lists… in many cases, in the hopes that others will come along and either offer to help out or simply offer existing resources that achieve the same effect being sought. This is kind of the “lazy web” approach to GTD: “ask and ye shall receive” or something like that.
So, it seems your next step is to set up your own wiki and get some of that personal documentation out in to the wild! It’s not really about whether anyone will ever find it, but it certainly becomes useful when you can just point to pages on an existing wiki somewhere!
Good advice. I may just do that – perhaps we should create a joint one?
Well, we should probably add to existing wikis, like Tantek’s Building Blocks wiki.
Are there specific topics you’d like to record? Ironically, this would make for a really good web app… 😉
Thanks Chris! We’ve made a good [ab]use of this post during WineCamp as explained here: http://winecamp.cocoate.com/en/node/19