Unlike other engineering disciplines, such as construction, which has centuries to develop the science of quantity surveying, and other forms of cost calculation, software engineering is still in its infancy, and how the true costs of software development are calculated are yet to be firmly established.

There are a few core questions to answer in creating this much needed understanding:

1. How should individuals and businesses’ go about thinking about software development costs?
2. How can costs can be measured?
3. When should costs be considered?
4. Who should decide costs?

At the bedrock of the problem is that we simply do not have enough examples, in general, of how long the problems we want software to solve, take to resolve. Software is still in an artisanal or craft state – extraordinarily little software is standardised, and the means and manner of construction are not applicable in all cases. Software’s very strength in being virtually infinitely adaptable presents with it the dark side of it being infinitely interminable.

How to think about software development cost?

When individuals and businesses approach costing software – how should they do it?

The first piece of advice that we can give is that they should remember that the actual construction of the software often forms less than most of the total effort and therefore the total cost of building software. Since software is crafted by people the time that it takes to bring these experts to bear on a problem is very often the major driver of cost.

From this emerges a dilemma – costs associated purely with time, when coupled with workers who are performing technical or even esoteric tasks create great anxiety in the payer. The best way to build trust, and alleviate this anxiety, is to have frequent, scheduled demonstrations of the work being produced, as is often the case in methodologies such as SCRUM.

As humans, we want to associate the cost of something with the value that it creates for us. The challenge with software, is that very often the cost of the software has got very little to do with the value that it is going to create for the person who wants it.

What do we mean by this? The smallest shopkeeper has the same desires as the largest e-commerce giant, in terms of functionality and value – however only one has the resources to commission the work. As software is abstract, and often experienced at no or low cost to us as consumers by Tech Giants we have become disconnected from the true costs of resources required to build even a simple piece of good software. We are spoilt in modernity with many great pieces of mass market software and are often alarmed to discover the cost of truly tailored products.

The common analogy is the difference between haute couture and fast fashion: it’s all clothes, but the cost, consideration, and complexity of production and distribution differ significantly.  

For true cost is coming from the people that are going to build it, their salaries and the fact that their skills are greatly in demand worldwide, and therefore the local supply is massively outstripped by the global demand and therefore the price is also affected by that dynamic.

How to measure true cost?

Once the software is developed and brought into production then there are classical operating costs, such as the computing power required to run the system, as well as the myriad of regular business operational costs, both humans and other products and services which make a business viable. Should these costs be considered when utilizing software? The cost of changing thinking in your business staff, your clients, the broader market?

When we consider software itself the actual artifacts of software the elements are almost always dependent on human effort; and the classical measure of human effort is time adjusted by an expertise factor.

This is not liked by many, as it makes cost dependent on estimation – a broad and enduring problem as most software does not have comparable projects to measure against, again because of human factors and the fast rate of technological change.

What is often expressed, by both buyers and sellers, is some form of equitable value-based billing.

Many businesses and people have tried to solve the problem of value billing when it comes to the cost of software. The challenge here is that often, the value of the software is overstated in the eye of the buyers of the system, but for commercial and negotiating purposes understated. This creates a dilemma and makes it very difficult to estimate the costs appropriately for both sides.

When should costs be considered?

What about the question of when cost should be considered? Costs should be considered throughout the software development lifecycle from the moment the desire to build software begins to the point where it is designed, analysed, planned, constructed, and ultimately tested and released to the market.

Costs are ongoing in software, and experienced purchasers understand this, just as homeowners understand and expect costs to marry to needs within the asset.

Software can be thought of like any other asset. It depreciates over time, it has operating costs such as warranties, service contracts, modifications, and improvements. The challenge is that often software is not viewed as an asset by businesses – it is viewed as an expense.

Software can be viewed as something that isn’t value creating and simply taxing the operations of the business.

Perhaps in the years to come that mentality of evaluating the cost of software will change but at present accounting models continue to make an improper distinction between CapEx (Capital Expenditure) and OpEx (Operational Expenditure) as it relates to software development.

Who should decide on costs?

The question of who should decide on what the cost of a software project is complex.

At Full Stack, costs begin with the quoting approach.

The quoting begins with a director and architect along with other senior staff in terms of assessing the brief and deciding how long the project will take, what resources are going to be required, what is the expense of the skills that are going to be brought to bear.

This is based on the hundreds of projects we’ve completed over hundreds of human years of experience in the senior leadership of the business, bringing that expertise to bear.

The buying client has a big part to play in terms of establishing and managing the costs once estimated (and before). Why do we say this? Expectations are often a major driver of cost in terms of:

• the time to market
• the quality required.
• the reasonableness factor of the build ask.

Where to now – when thinking about cost?

Ultimately the best way to understand the true costs of a piece of software is to have been through the process of building it yourself. A bit of a chicken or egg problem to say the least.

That is a tremendous challenge because effectively the message then is that:

• you have to learn as you go
• you have to acquire the skills needed to be able to assess what should this cost through experience on how long should this take

For many business people, whether working in a corporate or whether they’re at a startup or building their own business that question is a difficult one to handle and it’s also a difficult thing to come to a strong conclusion on.

The true cost of software development lies in the costs of the people involved in constructing the software. Their time, their expertise, their abilities are ultimately going to drive out the cost.

The key to thinking about costs, is therefore to think about trust. Who can you trust to build your systems reliably, transparently, and with your business interests at heart. To do that requires not only technical expertise, but also a commercial nous and a willingness to bring touch choices for cost control through the lifecycle of software: from cradle to grave, in the full stack of technologies, people and processes that make up the software that powers our world.