Two Software Development Worlds

I was recently listening to an interview with Joel Spolsky.  The main subject is interviewing and hiring, but in the course of the interview Joel touches on an interesting point.  He says that there are two major types of software:  Shrinkwrap and Custom (listen around the 40 minute mark).  These have very different success metrics and thus should be created in different ways.

Custom

This might also be called internal or in-house software.  It is software that is written with one customer in mind and will only be run on one system.  This sort of software makes up, Joel claims, 70% of all software being written today.  Think about the intranets, inventory management software, etc. that IT groups everywhere are creating.

Joel makes the point that because custom software is only ever going to be used for one purpose and in a restricted environment, there is a steep falloff in return on investment.  After the software "works", there is very little advantage to making it better.  It is at this point that development should stop.

Another important point is that there really isn't any competition in internal software.  Companies won't generally fund two groups to write the same software.  This has implications for the definition of success.  For internal software, there will be a list of requirements.  If those requirements are met, the project is a success.  Being a little faster, slightly easier to use, or having one more feature doesn't make a project any more successful.

Shrinkwrap

Shrinkwrap software is software that is created for sale to others "in the wild."  This is software that is written for a general user category.  It might be shrink-wrapped software like Windows or Office or it might be web-based like Salesforce.com.  The important point is that it will be used in many environments by many different people.

Unlike custom software, the return on investment for shrinkwrap software is greater.  When the program is functional, it has only met the minimum bar for entry.  It must be much better (more robust, more features, more usable) before it can successfully compete.  Each feature, bug fix, etc. helps to increase market share.

These differences have implications for the type of person required, the sort of teams, and perhaps even the development methodologies that can be employed.  I'll revisit some of these implications in a future post.

Joel talks about some of these implications here.