On Ideas, implementation and iteration

I have way more ideas than I have the capacity to execute.

That seems not an uncommon issue among my friends, and unlike that saying about ideas, I actually dont think everyone has ideas. Or rather, not everyone is passionate about ideas or seeing them through to some kind of product/feature anyway (people often mistake opinions for ideas). But there are definitely a lot of idea people out there. And in today’s hyper connected world, this has enabled a slew of services ranging from idea gathering platforms like Uservoice, Kindling to complete “idea to product” services like Quirky to emerge. [Update: Wall Street Journal has a fantastic article on Ideas that you must read, also my friend Karl Martino has just published a post with 3 other links on ideas]

One thing I have come to agree with is the thought that ideas are merely multipliers of execution, i.e. ideas are great and everything but what really counts is the execution. Occasionally, when someone shares something interesting and someone dismisses it saying “Oh I had that idea a while back”, I wince. Its that kind of thinking that often leads to people posting stuff like this, feeling cheated of success that should have been theirs because they had the idea first.

Execution is everything.

Or is it? Yesterday I read a rather awesome post by Jeff Atwood on the growth of his company (Stack Overflow) and his continued belief in what he calls “Boyd’s Law of Iteration” based on the findings of USAF Colonel John Boyd:

Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning, or acting better. The primary determinant to winning dogfights was observing, orienting, planning, and acting faster. In other words, how quickly one could iterate.Speed of iteration, Boyd suggested, beats quality of iteration.

The same seems to be true of product development. Jeff references projects like Google’s Chrome and Android and how they are getting to be really successful because of their fast iteration cycles. The official Chromium blog recently published a post on the accelerated release schedules and further mention their three goals for the accelerated releases:

• Shorten the release cycle and still get great features in front of users when they are ready
• Make the schedule more predictable and easier to scope
• Reduce the pressure on engineering to “make” a release

Over the last few years, I have released quite a few projects including:

• FlexAmp: An online mp3 player that plays audio from an online storage system like Box.net (now broken)
• DiggGraphr: A treemap visualizer for Digg stories (now broken)
• EspressoReader: A desktop client for Google Reader

A huge personal milestone for me was EspressoReader’s second feature release. I realized that of all my projects (not including open source libraries like OpenPyro of course), Espresso was the only project that ever had a second iteration that actually evolved the app (my other projects have had maybe one or two minor updates for bugfixes). The funny thing is, I have a lot of personal notes on features for v2 of all of  them.

So here is why I think a lot of my projects never have a significant version 2:

• The developer itch is gone: I started a project because I was interested in a platform or an API and the part I was curious about is gone.
• The last 10% sucks: I realize that there are so many edge cases to consider. The app is very demoable but isnt at a point where anyone can actually use it for long without hitting a bug
• The damn codebase is a mess: To get to the part where the app proves the concept, I have taken shortcuts that have compounded on each other. So now there is a lot of work involved to get the app to a state where it has the same functionality as before but I don’t groan every time I open the project’s source.
• There is a shiny new toy to play with: These days its iOS and Android, both platforms I am interested in and spend enough time between 9-5 on to be able to take on a project involving em (well more iOS than Android as of now). Its really hard to stay focussed on a platform that is not the shiny new thing.

I hope as I mature as a programmer, I can curb my tendencies to jump off of projects for the above reasons. All I can tell you right now is that there is definitely at least a third version of EspressoReader coming out in the next few days :).

Author: Arpit Mathur

Arpit Mathur is a Principal Engineer at Comcast Labs where he is currently working on a variety of topics including Machine Learning, Affective Computing, and Blockchain applications. Arpit has also worked extensively on Android and iOS applications, Virtual Reality apps as well as with web technologies like JavaScript, HTML and Ruby on Rails. He also spent a couple of years in the User Experience team as a Creative Technologist. View all posts by Arpit Mathur