Innovation is dirty

Imagine clear white board with big letters "E=MC^2" on it. Is that your notion of innovation? Do you think that innovation is somehow pure and untethered? That is the romantic notion of innovation that I secretly cherish. This morning my views have changed after I watched the following talk:



The talk is about Voyager Flight, the first-ever, non-stop, non refueled flight around the world. What does this have to do with innovation? This guys set out to do something nobody has ever done before. They took a risk by setting an audacious goal. They followed through despite all the odds. I want to learn to be like that.

I found it fascinating how far away they have deviated from their original design. Only the core of the idea survived: the non-stop, non refueled flight around the world. The plane design has undergone a number of major revisions.

This talk introduced some new ideas and reinforced some of the thoughts I mentioned earlier in [1]:

Focus on the goal/problem
If anything will survive, it is going to be the core of the idea. That should be the focus of efforts. There is no need or reason to cling on to design decisions that are not optimal. However, it is important to keep track of what works and what does not.

Iterative development
The initial design of Voyager was totally wrong in retrospect. Even the initial metrics for choosing components were wrong (weight vs. in-flight efficiency). However, those were best decisions at the time. Test flights proved indispensable in learning what work and what does not. Keeping an open mind for change is crucial. They learned from each iteration.

Attitude is key
Despite of all the test flights and advanced calculations there were a lot of unpleasant surprises during the flight. Some of them seemed fatal. At times pilots were saved by pure luck. At other times, they saved themselves by reconfiguring the internals of the plane (the fuel system) in flight. Had they given up, they would not have made it.

Another interesting idea that Voyager design is tied to is creativity in the presence of constraints. I plan to learn more about this idea as well.

Economies of Focus

How can small start ups compete with blue-chip giants? I've always wondered about that. Being somewhat of a (recovering) pessimist, it always seemed to me that the little guys have not chance. Yesterday, I watched this video:



The video is about a small company BitPusher that provides web operations and consulting services very similar to big players like IBM. The speaker isn't great, but the lessons are interesting:

• start out focused on a small set of services
  
• acquire and/or develop human expertise
• naturally migrate from one off to automated solutions
• one off -> copy & change -> template -> automate
• IMPORTANT:
  
• avoid temptation to automate things right away
• systematically keep track of all internal complaints about the current process
  
• prioritize: upgrade only parts of the process that really need upgrading

A one line summary would be: start out focused but have a vision (process) for growth.

This video echoed few thoughts:

Focus is crucial.
Small businesses should focus their efforts (only big businesses can afford to diversify). For me that means that I should try to implement the core of my idea. I often find myself coming up with ornaments that make the idea look more appealing. I guess I am counting on some sort of synergy between small ideas. This presentation is yet another reminder: stay focused.

Extract instead of inventing.
This idea isn't new either, but we make this mistake of putting the cart before the horse way too often. People in the computer science love to invent architectures and frameworks. However, only a tiny portion of these end up being used anywhere. Agile development and extreme programming books stress the same aspect: abstractions and generalizations should be driven by demand only. Which brings up to the next point.

Keep a log.
There is nothing groundbreaking here either. This guideline just says that one should learn from history. If some practice (or an idea) has been proven inconvenient (or inaccurate) note it. That way you'll have a list of things you can reconsider later.

Use your log.
Clearly keeping a log isn't going to solve any problems by itself. However, it helps you see the patterns. You'll know what you need to fix. The important thing here is to review your log regularly and to apply changes to your process.