Software Economics

Now the project was funded
we could all go back to playing Candy Crush

Software projects cost a lot of money. Some of them stretch to sums that would have made Howard Hughes cry like a two-year-old being babysat by Marilyn Manson. It’s lucky that so many are funded by big companies and government institutions with deep, continuously-filled, pockets because otherwise nothing would ever get finished. Yet a lot of very good software is also cheap, even free. Part of the reason projects are expensive is because businesses view software in all the wrong ways and part of it is because some developers, even really good developers, also see software in all the wrong ways.

Let’s take the business angle first. Company accounts are essentially made up of two kinds of expenditure - that which is spent on things that are then owned and may be sold (cars, furniture, offices) and that which is spent on things that are merely consumed and disappear (stationery, cleaning products). The former is filed under capital costs (capex), the latter under operational costs (opex). It’s all just money of course but during the financial year both are subject to differing levels of scrutiny.

Operational expenses are (in theory) mostly made up of the cost of doing business. Not waste exactly but kind of an annoying necessity. For example, staff costs are a classic operational expense. Ideally, in purely financial terms, staff would work for free, but they don’t - they have families and lifestyles and hobbies and they want money to pay for them in return for their services. Operational costs are bad. Reducing them is good.

Capital costs are not so bad. Or at least it’s fair to say given the choice between a capital cost and an operational cost a capital cost is preferable. Capital costs represent investments. If I buy a car or a building I can sell it. I might even sell the building for more than I bought it for and make a profit. In the case of the car the depreciation due to wear and tear is a loss on my investment which is useful for tax purposes. Maintaining the car is an operational cost (bad) and is generally to be avoided where possible.

That’s a very naive and simplistic view of corporate finance. Operational costs do have some advantages. Rather than buying my building it might be better for me to rent one. This has the advantage that I don’t need a loan, pay no interest, pay no maintenance, don’t need a deposit and my future costs are predictable. They’re also comparable with other buildings to rent. Opex costs are still bad but they can be more easily reduced if they can be compared. Also, if I ever need to move I simply give notice on the building contract and I’m free and clear. This is why some companies buy buildings through one part of the organisation (capital) then rent them back to themselves (operational) and why good corporate finance directors get paid a lot. Capex costs can be bad in this kind of circumstance because it’s not so easy to make comparisons where future costs are less predicable (and value of investments go down etc).

Software is tricky. Paying a monthly fee to use the SalesForce or AWS platforms is clearly an operational expense. You never get to own the core software, and you can’t sell it on, but it is easy to predict future expense. So what about software built in-house? Well, every company I have ever heard of sees it as a capital expense. I get this at the high level because it’s supposed to be an investment and it’s also something of a product (in agile we even refer to the lead source of business direction as the Product Owner). It’s a thing, an asset, a commodity with value, therefore it’s a capital expense.

In practice that view is mostly hokum and horsefeathers.

First of all bespoke software is not a transportable thing. It’s a vehicle for providing a service. Unlike a car (that provides the generic service of ‘transport’) software product builds provide the specific service of ‘what you asked for’. Generic things (buildings, cars) can be sold because they are generic, specific tailored things can’t realistically be sold - though that hasn’t stopped many companies from trying. I have many times uncovered issues in builds where the basis for all work has been on reusing some underlying “product” designed for an entirely different purpose because it was seen as a quick win.

Software projects are capitalised because they are a very useful way to re-assign all the hours of effort from all the people who work on them from the column marked operational (bad, wasteful, overhead) to the column marked capital (good, investment, depreciable, asset). Yet the effects of this sub-optimal categorisation don’t stop there. Software products aren’t ever complete in the way that a car is complete. Projects start, deliver code, then continuously deal with known requirements that weren’t ready in time, new requirements that only surfaced when the service launched, bug fixes, changes to meet shifts in external market forces.

There may be a nominal point in time at which the ‘project’ (capital) ceases to exist and transitions to a phase known as business-as-usual, or BAU, (i.e. operational) but it’s largely artificial because BAU is really just a smaller version of the project, run with limited resources and some constraints on scale of change. Except in rare cases (embedded systems that aren’t easy to access), software never stops. That’s because software reflects the needs of people and people never stop coming up with ideas. You can’t do that with cars, even though the idea might be interesting, because upgrading millions of vehicles would entail a ton of engineers doing time-consuming expensive work and it’s cheaper just to feed those improvements into the next model.

This obsession with capitalising something that’s not intrinsically generic or portable or saleable is in part what leads to organisations buying big vendor product suites, because it further adds to the illusion of having an asset.

And talking of assets, here’s another one - software, in any form, is not an asset. An asset must be at once useful and desirable. Software may be useful but it’s not desirable.

A healthy number of software developers these days ascribe to the idea that less is more. That simpler (simplest) solutions are always preferable to complex ones. The simplest possible solution is, of course, none at all. Find a way to avoid the original requirement and, hey presto, no software needs to be written.

I appreciate that this may be an unwise thing to say for someone who gets his mortgage paid via the delivery of software but let’s be truthful about this - every line of code that exists is a potential source of future expense, either an expense because it needs to be changed to meet new requirements or because it’s the source of a defect. Or because it was never necessary in the first place so it just adds to the general complexity and inertia in making system change.

We know all this is true because we spend a lot of time trying to do things with fewer lines of code, which makes things easier to read (sometimes) and gives us less to understand later when changes are needed.

The best option though is not to solve the problem with less code but to do less. I don’t mean the minimum viable product, agile, lean, view of do less. The whole focus of a good product delivery team should be to tease out the value that contributes to success and make that real. But an awesome product delivery team takes that up a notch and questions the value of the value itself, with the express intent of avoiding writing code to do things that masquerade as value but in fact are merely change liabilities for later.

Let me explain that better by way of an example extrapolated from a recent project:

A business that sells cars might also provide a loan service to enable customers to more easily afford to buy them. Customers have a choice to buy the car outright or take a loan out. If a car costs 10,000 Euros then buying it over 10 years at 10% interest will cost the customer 132.15 Euros a month and they will ultimately pay back a total of 15,858.09 Euros. A software system to manage this needs to make these calculations and so, if you were to approach this in a test-driven way, you can quite easily start to model some expected behaviours based on monthly payment for known loan amounts and durations etc. The valuable value is mostly clear - without these behaviours the system can’t manage loans, thus no product could be launched. Success (for this set of stories) is managing loans.

It isn’t the job of the software to do more than this though. It isn’t, for example, the job of the software to have an opinion about what price the cars are sold at. If the business sells cars too cheaply or at too high a price they may go out of business. It isn’t the job of the software to make sure that the total loan payment is greater than the cost of the car. If the business wants to sell car loans at a loss that’s their decision. Besides, they may wish to do that for very good reasons such as when the shortfall is made up via other means. Software isn’t there to safeguard the business, it’s there to do the simplest job possible in the simplest way.

Software doesn’t kill businesses, people kill businesses.

Or at least people should be free to kill their business (or free not to). Software complexity does unfortunately kill businesses in slow and imperceptible ways because it’s financially managed as an asset and because we put too much business opinion into software that isn’t direct “valuable value”.

Whilst software isn’t itself a financial asset it can be an asset generator. This makes it a lot like the staff that form a business. Businesses hire people to do good things that (we hope) generate value for the company. The annoying phrase “Our people are our greatest asset” is of course demonstrably wrong. The people who generate value are useful and desirable (despite being financially managed as operational overhead) whereas the ones who play Candy Crush all day are not. Neither are tradable commodities with a discernable exchange value. Quite the opposite. A company’s top performers, if they were to exchange their position for one at a competitor, could actually have a detrimental impact on business value (corporate secrets passed on, know-how used to improve competitor market position etc).

Good people are certainly critical to a business. They generate assets (or wealth to acquire assets) even though their individual intrinsic value is hard to calculate and they can’t logically be traded. And the same is true of good software. Social commentators have been talking for years about how software takes people’s jobs because their roles are often interchangeable. Nobody says software took away the role of the company’s buildings or real estate.

This is why it’s so very dangerous for a business to pretend that software isn’t core to their business when it clearly is. Companies that sell shoes, bananas, fix plumbing, fly aircraft or paint bridges are all software companies as much as they are people companies. To pretend otherwise is imprudent and reckless, equivalent to saying top performing people aren’t core.

The problems begin at the very top. It’s not often you see CIOs and CTOs given equal billing with HR, Marketing and the COO. It then extends to poor budgeting and the delusion that software isn’t actually part of the business but a financial commodity that can be traded like a building.

So the problem is finding valuable value (asset-generating functionality) whilst recognising that software is a major part (sometimes the major part) of business success.

Extracting valuable value is hard. It requires a single-minded focus on the conceptual integrity of the raison d’être of the software (literally, why it needs to exist). Conceptual integrity is easier to maintain with smaller groups because as per Brookes Law communications channels grow wildly as group size grows. Simplistically we often say that team sizes should be kept small. In Bezospeak they should be small enough that they don’t need more than two pizzas to feed them. While this is true it addresses the problem of productivity not economic cost-of-production. Smaller teams do cost less but in large companies that represents a tiny fraction of a project expenditure.

Applying this same “valuable value” concept to the project organisation we can identify two sources of valuable truth. The first is (somewhat obviously) the mind of the person, or persons, responsible for the concept. Who really understands what it is that will make a difference to the company’s fortunes? We may call these Product Owners but in reality they are really proxies for the board of directors. I’ve talked requirement management to death in the past, so no sense covering that ground again other than to say there are people in the business who know what needs to be done. They may need it surgically extracted from them but they know, they just require the appropriate counseling process to divulge it (and to separate it from false value).

The other source of truth is the mind of the developers because from the pool of “what needs doing” they know “what’s already done”. Software project economics hinge almost entirely on the balance between what needs to be done and what’s already been delivered. This tells us: what we’ve already spent (per story/function point), how much is left to do, how fast we’re getting stuff done (velocity) and when we might be finished. Though I’d reiterate that “finished” is something of an arbitrary notion. I prefer to think of desirable dates for feature set launches and desirable dates for a move from one level of resourcing (which is what a project is) to a lower level (which is what BAU is).

An idealised model would link these two sources of truth together without signal noise interference. The problem in the real world is that business value extraction is a specialised process that requires a rare set of personal skills. Good Business Analysts need to be both patient and somewhat combative to extract valuable value. Project bloat (i.e. cost increase) occurs when Business Analysts are patient and diligent but not directly forceful enough to separate false value from valuable value. Good developers, in my experience, don’t have the patience for this. Nor should they. Good developers are highly-trained puzzle solvers with a complete lack of tolerance for unnecessary procedural overhead or time-wasting frippery. It’s what makes them look for simple solutions over convoluted complexity. It’s also why they distrust architects who have a habit of dealing only in time-wasting frippery. Though in defence of good architects they can be useful by helping wrap valuable value requirements in the warm comfort blanket of non-functional requirements and pointing out what services already exist that would save those impatient developers reinventing wheels.

Unfortunately the enterprise world is far from this ideal. These two two truths have an economic value which gives rise to a complex community of traders and arbitrage activity. Andrew Pattinson once insightfully described this situation as an information Ponzi Scheme whereby every hanger-on in the company forms or joins some variant of a value-adding quality assurance oversight committee, peddling scraps of (usually inaccurate) information to any manager that will listen with the promise of greater insight to come, in return for some investment of political recognition. As this slideware works its way through the company it creates work-groups tasked with finding solutions to problems that don’t exist.

This is where the money goes. This is why software projects are so expensive.

The most disturbing aspect of all is that it’s unnecessary. If CEOs woke up an saw their companies for what they are, they’d place their CIO where they deserve to be - at the top table - and hold them suitably accountable. Finance director’s should stop chasing the tax advantages to capitalising project expenditure. The savings from doing things well would far outweigh them anyway.

Software creation is an asset-generating operational overhead. The complexity of which can lead to higher monthly operational/maintenance costs. Thinking of software this way may seem strange but it would have the advantage that the amounts spent would come under a different kind of scrutiny, just as hiring people does. The sort of periodic scrutiny that would empower delivery teams to focus on what really needs to be done, and ideally find things that do not need to be done at all. And for anyone doubting software can be built using opex budgets - it is. All the time. A typical enterprise makes its IT department beg for capex budget to fund projects whilst allowing the business (for reasons of speed and agility, naturally) to splash out opex on any smooth-talking software supplier with a plausible manner and a couple of rookie PHP developers. Once these systems are in production and causing the business pain they are invariably handed over to IT (for reasons of good governance, naturally) to support with their opex.

So yes to opex, but clearly I’m talking about the preternaturally controlled opex of the IT department. And finally with all this operational diligence it becomes that much more difficult for projects to be treated with a capex cargo cult mentality, where groups wait for the next air drop of over-funded poorly-scoped ideas to finance their next information Ponzi scheme.

Software isn’t evil, it’s liberating and powerful when appropriately applied, but, like alcohol, it requires a certain parsimony when determining how much of it you need if you want to enjoy it without consequences.

Notes

• The painting is called “Barrels of Money” by the French-American painter Victor Dubreuil, which was created around 1897. Quite a few of his works depict money. His life though remains somewhat shrouded in mystery. You can find more about him here

• The subtitle is from Shakespeare’s Measure for Measure