Making All Software Into Tools Reduces Risk

Here’s a radical idea:

All software should be a tool or language because it reduces your risk of failure.

I’ve written before that if an area is important enough, it eventually becomes a language.  We’ve watched it happen over and over again, sometimes in the most unlikely places.  For example, Adobe made it’s start by turning printing into a language called Postscript.  It gave them enormous advantages over the competition.  Here’s another prediction: we won’t see the real universal Social Graph until it is expressed as a language not an application.  Why?  Because as I have said before, it is a living breathing dynamically changing entity that means a lot of different things to a lot of different people.

Why do I say tools and languages are lower risk?  Certainly this flies in the face of conventional wisdom.  Many VC’s, for example, want no part of a tools play.  They see it as extremely risky for a variety of reasons.  Dealing with IT and other technical types seems hard.  As customers they are seen as too demanding.  They want it all for free as Open Source, etc., etc..  That’s one particular market, and there are answers to those questions, but making software into a tool does not necessarily require that you sell to that market.  Sometimes, the tool nature is almost invisible.  Spreadsheets, for example, are really languages.  Creating a spreadsheet is an odd form of programming.  In fact, it’s great because it’s probably the most widely used and understood language that’s ever been created.

Here’s another way to look at it.  I recently wrote an article called “Why Small Software Teams Grow Large“.  It was a response to a number of questions that had come up over my proposition that you need a small team to write really great software.  Here is a question that relates to this post:

Aren’t all the great small team examples tools?

Linux, Delphi, and Quattro Pro are described by Chris as “generic tools built without regard for any specific business logic.”  There are two ways to think about this.  Chris takes the path that says the example is irrelevant because most software isn’t that way.  I take the path of saying that the example is spot on because all software should become a language if done right.  The benefit?  Your small team is enormously more productive as are your customers if you can actually make the language something they can grasp and use.  There is a reason these small teams built languages (though I’m not sure I view Linux as a tool/language).  In fact, Quattro Pro had no less than 18 interpreters buried in the guts.  Very few of them were surfaced for end users, most were there to make the code simpler and the product more powerful.

You see what’s at work there?  Languages/Tools make it possible for smaller teams to be even more productive.  If you buy into the idea that small teams are the best, you must want them to have the best possible tools as well?  What could be better than to make the software they’re working on a special purpose tool?

I’m certainly not the first one to think of things this way.  There is an entire area based on the idea of Domain Specific Languages.  The idea is to create a language around the problem you’re trying to solve in order to make it easier to solve the problem.  Tools like Ruby on Rails or Lisp are extremely good at that task.

Rather than dive into a highly technical tangent, let’s get back to the theme here.  Why would making your software into a tool reduce risk?  We’ve already hit on one aspect–it can make the developers much more productive.  Here is another: a tool makes it much easier for the software to adapt to changing needs of customers.  I do a fair amount of what I call “Termite Inspection” for various VC’s around the Valley.  Some of these engagements boil down to, “This company has a great idea, but they seem to be stuck in a rut.  What should they do?”  Many times what has happened is a company started out with a great idea and some knowledge of the domain.  They built a piece of software that is a very literal embodiment of their view of the domain.  So long as the whole domain and all the customers fit their view, life is good.  However, for most non-trivial (i.e. interesting market size) domains, nobody knows the whole domain.  You learn as you go.  Customers throw curve balls.  If the only way to adapt to that is to either keep adding tons of features to the software, or do expensive custom work on each deal, that’s way too much friction to scale.  A domain specific language makes it possible to manuever a bit at low cost and give customers what they want.

I finally put two and two together on just how important this can really be when reading Fred Wilson’s excellent article on Why Startups Fail.  Interestingly, he classifies all of his failures (and presumably others) into two categories:

1) It was a dumb idea and we realized it early on and killed the investment. I’ve only been involved in one investment in this category personally although I’ve lived through a bunch like this over the years in the partnerships I’ve been in.
2) It was a decent idea but directionally incorrect, it was hugely overfunded, the burn rate was taken to levels way beyond reason, and it became impossible to adapt the business in a financially viable manner.

Can you see where this is going?  Category 1 won’t be helped, and Fred correctly says you can identify this and cut your losses early on.  Building the software as a tool is a perfect antidote to #2.  The “decent idea but directionally incorrect” is strikingly similar to Marc Andreesen’s concept of achieving a product/market fit, which he says is the only thing that matters.  Fred Wilson gives us a great anecdote:

Dick Costolo, co-founder of FeedBurner, describes a startup as the process of going down lots of dark alleys only to find that they are dead ends. Dick describes the art of a successful deal as figuring out they are dead ends quickly and trying another and another until you find the one paved with gold.

Achieving the product/market fit is a matter of trial and error.  It is searching through an unknown territory filled with dead ends.  To survive, succeed, and prosper, your software needs maximum flexibility and adaptability.  That’s the definition of a Tool.  It can be adapted even as the requirements keep changing radically, and it can be adapted very cheaply and efficiently.

The principle should be clear by now, but there are troubling questions of practice. 

First, creating a tool sounds harder than writing an application.  My answer is that it’s harder because of who can do it and who can’t.  Once the tool is created, any developer should be able to use it to create new features.  Creating it is the province of developers a notch or two above the lowest common denominator.  The good news is that you don’t need to many of them.  Given my preferred maximum team size of 10 developers, you should easily get buy if 2 or 3 of the 10 are language creators.  Look for people who’ve done it before and are comfortable with the idea.  Look for people who are adept with dynamic languages and tools like Ruby on Rails. 

Second, delivering a tool sounds like a nightmare for users.  What do you do if your users are not technical?  Just because you’ve delivered a tool doesn’t mean you have to leave sharp blades and flaming torches hanging out of the toolbox.  Nothing is easier to attach a user interface to than a language.  That’s one of the great beauties.  But here’s a real quantum leap: combine your application-as-tool with a ui-as-tool for true power and flexibility.  I’ve been working with Adobe’s Flex along those lines and the results are amazing.  Other combinations that are similar to this would be combining something like PHP, which could be viewed as UI-as-tool with your application.  This is how the various social web 2.0 sites have gotten going so quickly and cheaply.  PHP straddles both sides of the spectrum and allowed these organisms to evolve very quickly.  In the end, you will wind up with a much better user experience because you’ll be able to quickly evolve your UI based on feedback.  Take it into usability testing early, and the combination of application and UI languages will make it straightforward to act on recommendations.

I hope you can get a sense from this post how powerful a competitive weapon having a language versus an application can be.  It actually reduces your costs, increases your flexibility, and let’s you respond with ultimate nimbleness to market demands until you’ve found the best possible product/market fit.