I bet I’m like a lot of software developers in one particular way: I nurture ambitions of one day starting my own software business. Sometimes I fantasize of selling a product I’ve dreamt up, and other times I imagine running a small dev shop doing custom development for customers.

“The Business of Software,” by MIT business professor Michael Cusumano offers a handful of characteristics of software businesses that a daydreaming developer can use to evaluate their fantasies in a more analytical way. The thrust of Dr. Cusumano’s book is that he’s come to find that a handful of criteria can be used to design or evaluate a viable software business.

The book was written in 2003, nearly 20 years prior to this 2021 review. That added a dimension to the experience of reading it. We in the software industry are now living in fat times, similar to the 90s. Reading this post-crash book, which pays extra attention to surviving in challenging environments, was a good reminder that it won’t always be like this.

What’s also fun to discover is that Dr. Cusumano proposes several ideas that have emerged over the years as the consensus opinion. A couple of examples are his proto-continuous integration approach dubbed “sync and stabilize” as well his an embrace of evolving product requirements, which feels an awful lot like agile development and “The Lean Startup.”

A good chunk of the book is spent considering the merits of building a product company versus a services company versus a hybrid business (which inevitably leans in one direction or the other). Dr. Cusumano leaves room for the entrepreneur to decide for themselves which is more suitiable based on their own circumstances, but generally speaking, he favors the hybrid company.

He views the decision as one of diversification, where the product development is informed by the close customer collaboration of the services arm. He acknowledges that a product-focused business has no marginal costs and can print money when done right, but he notes that the money printer’s plug can get pulled quickly if there is not a services component that more closely ties the customer to the vendor. Written in 2003, this suggestion is clearly influenced by the dotcom crash.

There was a lengthy chapter on software engineering techniques. I think there were useful nuggets in this chapter (mainly related to fitting the appropriate technique to the business needs), but I found it to be academic and very dry. I’d recommend skipping it for any reader with a basic understanding of software management techniques.

The book culminated in a chapter of start-up case-studies. This was really fun to read, and I think it was useful because each business was evaluated with the same criteria:

  1. Strong management team
  2. An attractive market
  3. A compelling new product, service, or hybrid solution
  4. Strong evidence of customer interest
  5. A plan to overcome the credibility gap
  6. A business model showing early growth and profit potential
  7. Flexibility in strategy and product offerings
  8. Potential for a large payoff to investors

I guess it can’t be a book by a business professor without case studies. As someone who has not attended business school, it made me appreciate the case study method. Each case was different, but taken together and analyzed with a consistent framework, they helped me to appreciate these eight criteria.

My favorite case study was the first presented: NuMega Technologies. The company was created in the 90s by two coworkers from a flailing employer. They left their jobs and struck out together. They were analytical, deciding that as two individuals, they had to build a small product and it should be focused on a category they knew well.

They were developers, so they built small developer-productivity tools that were too niche to be noticed by the larger players. After selling 100,000 copies, largely to individual developers rather than to large IT departments, they sold out Compuware for $150 million in stock. Compuware was invested in mainframes and used the acquisition to expand into the Windows ecosystem.

“The Business of Software” is a book that shows its age, and I think that’s a good thing. Most of the lessons here are still applicable today, and its post-bubble publishing date makes for a healthy reminder and fun comparison. Compared to a lot of business books, the book is slightly more academic. I think that was worth the extra effort because it gave me a framework for evaluating my current employer’s prospects as well as all the business ideas that pop into my head.