Is software an asset or an expense?

I had a brief conversation on Twitter with Camille Fournier () about costing for projects and development, and this is something that I’d been thinking about (but not writing about) since I was at ANZ bank about 2007 or 2008. Most of it was trying to explain/understand expectations about software development and delivery and “how much effort to put into projects”.

Even though I actually have a commerce degree, I don’t intend this observation to be a strict treatise on the accounting terms “asset costing” and “expense costing” but more about the general expectations set by considering the constructed software as an asset, or an expense.

The basic premise is that in general teams of software developers, in the absence of specific direction or rules will assume that the software being delivered will have the properties of an asset. The software will last for an extended period of time, it will be modified and updated and will not generally have a short defined end of life date.

However, in many cases the teams of people asking for software to be built will not always have the same view, and they may be well asking for systems that are developed in shorter time frames, and have a short defined end-of-life date. This generally is where the difference in expectation on project cost (and time) often comes from. We see this a lot in start-ups, where iterating and responding to new ideas trumps all possible long term benefits. With nothing right now, there is no future for the start-up.

Coupled with this particular problem, there is generally a mismatch between how much effort the demand team expects the supply team will take to construct a solution.

So, what should we do about it?

At REA, I’m starting to help our teams with this, and the first step is to get some greater definition about the expectation of not only what problem the system should help solve (“functional requirements”) but also the scope of what that system should participate in (“non-functional requirements”).

Generally these would be called something like SLA (service level agreements). How many users will it support, what is the uptime? What is the response rates? What are the transaction rates? These are pretty standard non-functional requirements that you’d see in systems descriptions. However, one key part that I’m trying to encourage people to think about is “how long should this last?”.

I think the first part of the problem is trying to get an understanding from the customers about what their goals are. Do they want to create some “disposable software” to solve this problem? Do they think that the solution to this problem should last for a long time and be enhanced over that time? Do they even understand there is a difference to the engineering required to do this?

Now, if we add to this the general trend towards microservices (smaller units of functionality that can be more easily replaced) maybe we are looking at a general shift in the way we write code for systems and how we might wish to think about, and set expectations for system development. Can we really think of software components as “write them to throw away”?

Certainly if we’re looking at treating the components or code like an expense, I think there’s a better chance. I also think that using expense based thinking for “research and discovery” might lead to more opportunities for faster iterating through ideas, knowing the expected use and lifespan of the work performed.

I’d also like to see more input from people who have tried similar ideas. It’s a slice of a topic about “software life-cycle management” that is more deserving of thought that most teams give.

Advertisements