My take on Utility and Strategic software

Recently, Jez Humble examined the Utility/Strategic dichotomy defined by Martin Fowler, to find out where the continuous delivery concept applies best. Here is my take on what I learned during the last years on this distinction.

Definitions

The basic idea: a software's role into a business is either into the utility or the strategic categories.

• the utility category identifies software that just needs to work, regardless of implementation of technical details. Examples of utility software are payroll systems, mail servers, and most project management software.
• The strategic category identifies what makes money in the short and long term, giving you an advantage over the competition. Think of Google's PageRank or distributed file system, or Amazon data centers which spawned AWS.

The utility/strategic categorization is about the role of the software, not considering it in isolation: the CRM seen as an utility for you is usually a strategic project of the firm that sells it.

Open source

Let's start with a bold statement: all open source developer-oriented tools are utility, not strategic projects.

Many open source libraries, frameworks, and tools are adopted automatically, and an outsourcing decision is consistently made: to download them instead of reiventing the wheel. You would never outsource to a community for a product developed by your own work, unless you are following some particular business model like selling a complementary good. If you outsource your competitive advantage, you'll be soon out of work.

Some open source examples of utility software: Subversion, Git, Apache, almost all web application frameworks. You don't care how Git is implemented as long as it works well, lets you work disconnected (key feature) and generates diffs quickly. And you don't care in what language Apache is written in, as long as you can add logging, compression and access blocking with three lines of configuration.

If these utilities were not available, you would just choose a different tool in substitution. It follows, from their status as utilities, that spending your development time or even free time to improve your working knowledge of them has diminishing returns.

Unless you are a system administrator: in that case, you should know Apache's mod_rewrite syntax by heart as for you it is a strategic skill to sell to your employer.

Profit center and cost centers

It is interesting to map utility and strategic projects to the concepts of cost and profit centers. Cost and profit centers are loose terms for business units that spend or produce money (forgive me for the quick definition.)

An example of cost center is a team building the website of a brick-and-mortar company (not of an online one). Projects in a cost center are usually viewed as utility software: reducing costs is the imperative.

Of course, not only software can be considered an utility: the bigger the company, the more people are employed in cost centers. Lawyers, HR, and secretaries are an expression of necessary cost centers that keeps the company working well. Only as revenues are high enough to support them, and the complexity of the organization increases, these roles become mandatory.

In the case of software, the problem with utility/cost center projects is that they're prone to outsourcing, or to the buy side of the *build vs. buy* decision. Thus it's considered riskier to work in a cost center, both for your salary and career, with respect to a profit center.

If you work for other companies you are always a cost center for them, but you're supposed to provide greater value than the money spent on your services and products: your role is that of a profit center.

For the best examples of profit centers, look at product-based companies: 37Signals or Paypal programmers spend their time into developing a product which is sold every day, in terms of subscriptions or transactions. I use smaller companies examples because Facebook, Amazon and Google have grown so much that it's not immediately clear whether a team is a cost or profit center in there.

In any case, what we can see from the outside of 37Signals is the strategic subset of their projects: the code that makes money in a way that others are unable to do (for now). In many cases, there's not even a question if one should build or buy: a profit center should be kept at the center of a company. Increase profit is the imperative, not cutting costs.

Your abilities

I believe that as a passionate programmer gains expertise and experience, he faces a natural transition towards profit centers. Your abilities won't be used fully if you stick to cost centers: there are dimishing returns in applying Domain-Driven Design and Test-Driven Development to a Wordpress application.

I'd like to say I followed this transition consciously, but I didn't. As I progressed in the programmer's journey I and product companies became attracted, due to:

• more interesting technical problems and application domains on their side.
• The possibility of continuous involvement as a product evolves instead of a fixed period of work on a one-shot website. Here's where all those fancy refactoring techniques and coding katas pay off.

My view of company websites is based on what I worked on several years ago, but if they have become profit centers in the meantime it's good for all programmers working on them.

Technical debt

A certain form of technical debt appears when a strategic component (or part of it) is outsourced to a tool which is considered utility. For example, when a framework or a library is adopted too quickly.

Many bad things can happen next:

• flexibility is harmed. You can't follow what the market wants because feature X cannot be shoehorned into this framework's model of web applications.
• Performance is harmed. The framework has so many pieces that they slowly move together. You discover it too late and have to code from scratch the component that was outsourced.
• Maintenance is harmed. The added complexity makes you spend more time hacking with the framework and debugging instead of adding features or user experiences that would bring you more money.

Conclusions

Distinguishing between utility, cost center and strategic, profit center software is crucial to decide in which company to work and what to borrow from open source. Take five minutes to look at the projects you're coding all day on through these dichotomies.