My favorite software quality metric is the income statement

I’ve been working on an open-source project for the better part of a year. It is very complex, very fancy, and has no users except for me. But I love it. It sharpens my skills and gives me a chance to discover puzzles and solve them in the most elegant solution possible.

But in the business world, this approach is downright silly. Nobody writes blank checks to vendors. Nothing in nature works like this either.

When a shark chases down and eats an unlucky spring breaker, the shark burns some calories during the swim, and then gets some calories back during the meal.

On average, the shark has to extract at least many calories while eating as it burned during the chase.

So on to the income statement. The shark makes a good metaphor for a software business. The hunt is the process of acquiring customers. The calories are the firm’s revenues and expenses. A lot of the quality of a software team can be measured in the income statement.

The perfect product is written once and it solves all problems and never needs any updates or extensions or bug fixes. The worst product has to be rewritten from scratch for every new customer and requires lots of bug fixes. Really well-written software falls somewhere between. It supports extensions, but they are quick and safe to do. Bugs can be quickly patched.

It wasn’t obvious to me initially, but this aspect is easy to measure in the cost of goods sold. If a firm lands a deal for $60k, but burns 160 hours rushing some tweaks through, then those hours drive up the cost of goods sold and drive down the firm’s margins.

You can look at the firm’s margins over time and watch whether the app is getting better or worse. Sure, there are mitigating factors, but in the long run, you can’t maintain an attractive income statement and a shitty code base.

9 thoughts on “My favorite software quality metric is the income statement

  1. I've been using Quickbooks, and I've noticed that it doesn't work very well if I want to show each segment's balance sheet and income statement.

  2. I have often found that bad code is likely to happen when you have too many requirements and too little time or people to do it in. Caring programmers, when given a fair amount of time, will write good code.

    Additionally, I have found that poor product vision also leads to less maintainable code. Good programmers, when given a strong vision about where the product is going, will make good decisions about what can be safely “one-offed” and what requires more serious design effort.

    I guess what I'm trying to say is that poor vision and poor focus can lead to a poor code base just as surely as poor programmers. Also, poor targeting of customers can also lead to poor code bases, as features are shoe-horned into a product whose vision gets blurrier and blurrier.

    So if you are looking at declining margins, ask yourself are we chasing after the right customers? Do we have the right product vision? Have we clearly defined the product vision and direction to our team? Have we found all customers for our code/product as it exists today?

    I recently read a good article with this statement, which I think in a manner sums up looking at things the other way.

    “There are always more things to do than there is time to do them. Startups are a continuous exercise in deciding what not to do. You can sometimes win by just not doing things faster than your competition.”

  3. Thanks for the comment!

    I see poor vision creeping in when landing the next deal takes on too much importance. I understand why the sales guys for rush into my office after every single demo and ask if I could bolt on half a dozen extraneous features. They're just trying to land the deal. I know that revenue really matters.

    But I spent our first year doing whatever our beta customers asked, and the app suffered for it. We had lots of unrelated screens, each with a different style, built for separate customers to do different things. It was a mess.

    Now I'm trying to balance the need to get that hockey-stick revenue growth chart against the need to keep the app from turning into a big unholy mess begging to be put out of its misery.

    It's fun.

  4. Ok I have this income statement here. But I am not too sure if its right. Can someone look over it and temme if I have the right entries under “other revenues and gains” what you say?

Comments are closed.