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.