Friday, March 13, 2009

Write Tools, not Frameworks

In the world of software, a reusable tool is almost always more useful than a framework. Of course, both have their time and place, but if you can structure your project as a tool, you probably should. 

So what's the different?
Tool (or Library) - Usually takes the form of an API that your application can call. Any application can make use of this library where and when they want to. If the end user wants more functionality out of the library they can either implement this on the side of their application or if it's general enough into the library itself. 

Framework - A set of shared code that is designed to be general enough for other code to extend. Frameworks can take the form of a set of an abstract classes that the user should override, or perhaps a set of rules about what the end user should do in his application.

A program plugs into a framework, but makes use of (or leverages) a tool. 

So why is a tool almost always more useful than a framework?
  • A tool can be used by ways unimagined by the original author. Since tools just provide an API, they can be used in almost any setting. The end user can use a tool in a java application, a web application, or a mobile application. A framework generally limits the end user to design a specific kind of application that the framework designer had in mind. A framework often doesn't have the infrastructure to enable the user to be more creative. 
  • A tool has less conceptual weight than a framework. In Josh Bloch's talk on designing a good API, he emphasizes the importance of minimizing conceptual weight. The idea here is that the end user doesn't want to have to spend a lot of time learning how to use something. A good tool should be intuitive, easy to understand, and do exactly what the user wants. A framework usually involves the end user having to learn a new way of doing things while a tool can just be plugged in to the end users' already built system.
  • A framework locks the user into using a certain codebase. If the codebase is buggy, the users entire program is buggy and he would need to find a new place to write his program. If a tool is buggy, the user can simply just not use it and use something else, but keep everything else he's already written. 
I think the most interesting point about this is that it's true on more than just a software level - it's also true on a kind of 'macro' level and is one of the main differences between Twitter and Facebook. Twitter acts as a tool - it offers an API that the end user can embed in any application he chooses. An application that makes use of Twitter can show up on the web, on the desktop, on phones, and I'm sure in many more interesting places in the future. Facebook, on the other hand, is a platform. All users who write a facebook application live in facebook's "walled garden". The applications are made to behave a certain way and must live in only one place. 

This is why Twitter is so much more powerful than facebook and will eventually win.

Saturday, March 7, 2009

What Palm Needs to Do to Win

The Palm Pre has been gaining a lot of hype, and rightly so. They're one of the original smartphone companies (remember when smartphone was synonymous with Palm Pilot?), and the previews of this phone has looked really sleek. They haven't released many details of the phone yet, but from the pictures it could be a real winner. The smartphone market is a difficult market to compete in right now, with stiff competition from iPhone, Android, and Blackberry. What can Palm do to win? I think these three things would guarantee a Palm in every person's hand.. ok that was a really bad pun.

1. It has to have an intuitive, non-buggy UI. This may seem pretty obvious, but for some reason companies haven't been able to actually produce a feature rich, non-buggy smartphone. The Blackberry Storm was a great example of a phone that looked good on paper but when it actually came out it was buggy and hard to use. I think Palm could realistically ditch a camera or even wifi if the phone had a nice and sleek browser, maps program, and contacts. Of course, the phone would have to be able to text and call well.

2. The phone needs to cost under $100. Smartphones are still seen today as something that people don't need. They're a luxury item for the rich and snobbish who like to have cute iPhone games in their pocket. I think if Palm prices this at $99 (which they never will, by the way), this would bring the smartphone into the mainstream. Yes, there exist smartphones at this price point on major carriers, but they suck (see #1). 

3. They need to make a deal with Verizon. This is killer, the #1 reason I hear people tell me for not getting an iPhone is "I'm locked into a family plan with Verizon". The next potential 'iPhone killer' NEEDS to be on Verizon. AT&T already has the iPhone, and Sprint/T-Mobile are just not big enough carriers to make a dent in the smartphone market. Palm is probably locked in with Sprint for at least a year or so, but they need to be first to get on Verizon.

If Palm makes a smartphone with an intuitive, non-buggy ui, prices it as under $100, and (eventually) makes a deal with Verizon, this phone will be the first smartphone that my friends who live outside of San Francisco actually use.