Monday, February 3, 2014; 6:27:15 PM Eastern
Hacking at complexity
- Take some job you do a lot and write down the steps. Number them, 1, 2, 3 etc. Then step back and look at the list and think. The same way you might think about an interesting crossword puzzle, or a bridge game. A SimCity. Your goal is to eliminate steps.
- I find that if there's an underlying simplicity to the problem, if it's possible to simplify, you'll figure it out.
- Now, of course sometimes to simplify you have to cut off options. Another way of thinking about this is you're paving a cowpath. Look to see what people do the most, where the path is most worn, where the tracks are deepest -- where the taverns and hotels went up. These are the places where it pays to smooth things out.
- A great example of this was Think C in the early days of the Mac. Think C had a shorter learning curve than a powerful command-line tool with a shell language. That was the downside. On the upside -- you could start having fun sooner. And the downside wasn't all that bad, because patterns had emerged, they were basically codifying and supporting processes Mac programmers were already using.
- I think we're in the process of creating the cowpaths now, in the emerging environment of static apps and server-side JavaScript. It's an interesting time to think about it, because development models are simplifying on their own, and with a little willfulness we could get there faster.
- Here's an A vs B to consider. I have a Node app to deploy. You could create an EC2 instance, or you could run on Heroku or Nodejitsu. In one case you get the full flexibility of a virtual PC. All the options. But it's still interesting to be able to drop a JS file in a folder, type a few commands at the shell, and have it run in its own process on a machine you don't have to even think about.
- Ultimately, I'd like to be able to deploy by choosing the Save command from a File menu in my editor. That would be the easiest. A 1-step deploy. ;-)