OnStartups

Author’s note:  I am a big admirer of Paul Graham and his writings.  Mr. Graham  is an exceptionally gifted  writer and thinker.  This is my first attempt at writing a longer, essay-style “thinking piece”.  Though my writing will likely never match his, it is hopefully of some interest and value to you.   Thanks for your patience as I experiment with this new format.  I would appreciate any feedback or comments you have.

Code Is Not A Commodity:  Why Software Is Not Like Soybeans

Every now and then, I hear someone say:  “software is becoming commoditized”.  The idea is that as the tools have gotten better and it has gotten easier and easier to build software products, the end result becomes a commodity to the point that it is no longer possible to differentiate a business based on the software.  Software, the thinking goes, is easy to replicate and as such, any potential competitive advantage that can be gained is temporary at best.  

I fundamentally disagree with this line of thinking. 

One of the core elements of a commodity is that various offerings are almost indistinguishable from each other.  This is why the classic commodities are things like soybeans and other agricultural products.  In many of these cases, commodities can (and are) traded on some sort of exchange.  What makes this trading possible is that the products are more or less homogeneous.  One ton of soybeans is about the same as another ton of soybeans.  When dealing with commodities, the market determines the price.

Now, let’s take a look at software.  One of the common arguments given as to why software is becoming commoditized is that the “tools are getting better”.  The thinking here goes that as the tools get better, it becomes easier and easier for people to create software products.  This leads to commoditization because software is less and less differentiated.  Since it is so easy to replicate a software product, the result is homogeneity.  I think this is misguided thinking.  Just because the tools get better and creating software becomes easier does not mean that the products are less differentiated and becoming commodities.  

As an example, back a long, long time ago (in computer years), the software industry evolved from using low-level languages like assembler into some higher order languages like COBOL, Fortran and C.  As a result, it became much easier to create software that solved similar problems than it was before.  The higher order languages allowed for better abstractions which in turn made it possible to write larger, more complicated programs – all other things being equal.  So, inarguably, back then, the tools for creating software got much better.  But, did we see a commoditization?  Were all software products practically the same because they were written in the same set of languages?  I would argue not. 

Given a relatively complicated problem to solve, even equally gifted programmers will come up with solutions that are often radically different in their implementation.  I’m not talking about just the user experience, but also the underlying design and architecture of the software is radically different.  Software development is often a series of tradeoffs and those developers that succeed over the long-term are the ones that understand the subtleties of the trade-offs and tend to make better choices for their given situation than their peers.  What makes a great programmer is not just picking the right tools, but in understanding the tradeoffs and making the right choices. 

One of the outcomes of good software design and making the right trade-off choices is that over time, the better designed product “wins” as it is easier for that team to adapt to market conditions and exploit future opportunities.  Manyy successful software startups that I have seen can trace a large part of their survival and success to a core set of developers that knew what they were doing and were able to build a body of code that could be leveraged for future opportunities.  One of the biggest advantages of these small, well-knit teams is that there was a shared understanding of some sort of “meta framework” that made it possible for this group to do spectacular things that others could not.  Those companies that treated software as a commodity believing that simply hiring “the best programmers” and throwing them together to write code often failed.  They didn’t fail immediately, but they failed eventually because another group could leverage their code and exploit future opportunities better than they could.  Only a part of the value of software is what it does today in the form of a product that can be sold.  A large part of the value is what can be done with the underlying code in the future.  

Now, let’s look at the code itself as an “asset”.  Let’s assume we are looking at two different code-bases, written in the same language and that are more or less solving a similar problem (like a social book-marking website).  How does the market value the code itself?  That is, if both of these bodies of code were written by now bankrupt companies and being sold on the open market, how does the code get valued?  What would people pay?  The answer is, it depends.  What does it depend on?  Well, it depends on what can be done with the code.  Chances are, if the code is separated from its creators, its value goes down dramatically.  The reason is simple.  Code and its creators are inextricably intertwined.  The people that created the code are the ones that can best leverage it to create future value.  If you’ve ever tried taking over someone else’s software and maintaining it, you’ll know what I’m talking about.  

If code were a commodity, then it should be easy to value it and determine a “market price”.  We should have some way of calculating the relative difficulty of the problem, lines of code used, technical choices made (language, platform, etc.) and measure the “usability”  of the product through user testing and come up with an approximation of the value of the product.  If software were a commodity, it would be easy to do this.  But, as it turns out, it is not.  Much to the dismay of folks outside of the software industry, software assets are notoriously hard to value.  The reason, I think, is quite simple.  Software is not like soybeans.