Requirement #3: Run upstairs
What’s the spark behind Kinetic? One day last June, while working on an architecture diagram using Microsoft Visio, several of my neurons misfired, and it’s an itch that I’ve been trying to scratch ever since. The idea is simple: How can we use words to describe complex diagrams? For example, is it possible to have a tool that will allow me to update an organizational chart or a network diagram just by changing a few lines of text?
Granted, this isn’t exactly a new idea. Google and you’ll find dozens of programs. But I’ve yet to find one that satisfies my twin requirements of: 1) usability and 2) flexibility.
- The tool needs to be simple to use. The litmus test is always, “Yeah, but will my grandma be able to use it?” It should be dead simple to update the organization chart. AT&T Research’s Graphviz rocks, but in my opinion, the syntax might be a bit too arcane for the average user.
- The tool needs to be flexible. Can the software handle a variety of diagrams? Ideally, I’d like to be able to use the same software to generate both organizational charts as well as network diagrams. Tools such as Diagrammr are limited in the types of diagrams they can generate.
As it turns out, meeting both requirements is a hard problem. It’s a design challenge, a tug-of-war. Make the tool flexible, and usability suffers. And vice versa.
http://www.flickr.com/photos/kitone/2478029256/
I know it’s a challenging problem. The scary thing is–it might not even be solvable using current technologies. And that’s the very reason I’m drawn to it. Paul Graham calls this “running upstairs.”
Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him.
What this meant in practice was that we deliberately sought hard problems. If there were two features we could add to our software, both equally valuable in proportion to their difficulty, we’d always take the harder one. Not just because it was more valuable, but because it was harder. We delighted in forcing bigger, slower competitors to follow us over difficult ground. Like guerillas, startups prefer the difficult terrain of the mountains, where the troops of the central government can’t follow. I can remember times when we were just exhausted after wrestling all day with some horrible technical problem. And I’d be delighted, because something that was hard for us would be impossible for our competitors.
Thanks for joining me on this stair-run.