In the Geovation tech team we support start-ups as they embark upon new businesses – often around a software idea. Regardless of technology, it results in rapid development of a new product.

It’s important to help our members appreciate that beyond the feature development of their software, products always need ongoing investment.

There’s no ‘build it once and it’s done’. Apps and websites need constant maintenance. People understand the need for technical support and fixing bugs. But not for what we know of as ‘Technical debt’ and ‘Software entropy’.

Technical debt is how we describe the build-up of tasks that are frequently pushed back, usually by prioritising new features. A few examples are:

• Difficult code is skipped, and easier but flawed ‘hacks’ are used. These may cause occasional bugs, or make software run poorly. Too many of these and software becomes unmanageable, and hard to work with.
• Documentation is missed and held in people’s heads. This makes it harder to onboard new developers, as well as putting a growing risk on the business. Developers can, often subconsciously, encourage this situation by not recording important information, and increasing reliance on themselves.
• Testing is neglected or skipped entirely. Methodologies such as Test-Driven Development encourage software tests to be written before code. Whatever testing you choose, be aware that not implementing it from the start will increase tech debt, as well as bugs.

Software entropy is a little different. It describes the problem that however well you develop software, it is subject to rot and decay. Software requires time and investment to actively care for it.

Home ownership is a good metaphor for the software entropy process. Homes need maintenance – lights will fail, surfaces become dusty and dirty, and damp can accumulate. Leave a house for half a year without any maintenance and it will become uninhabitable.

A few examples of software entropy are:

• Software libraries becoming deprecated. We recently worked on a mobile app. Before we could write any new code, it was necessary to spend weeks upgrading the components before it could be accepted again on the Apple and Google app stores. If core components aren’t kept up to date, it could stop you when you need to fix a critical bug.
• Conflicting and varied software requirements can lead software in different directions to the original vision. The more features you bolt onto the software, the less coherent it becomes.
• New developers working on software cause an increased level of disorder. You may find you end up with multiple components that do the same thing, but in different ways. Ensuring you have good coding standards and peer review can help in reducing this.

Both tech debt and software entropy are related. Taking on too much tech debt can accelerate software entropy. You may decide a new feature can be temporarily delivered by a third-party software module, but that module is out of date and poorly supported. Adopting it creates technical debt and increases the disorder in your software.

How does a start-up reduce these problems? There are many individual steps that can be taken, but overall, it is about investment and good product ownership. If your offer to customers is a software product, you need to look after it as a key asset.

A product owner is responsible for prioritising a ‘backlog’ of development tasks, and these cannot only include new features. They need to ensure time is spent upgrading components, writing documentation, reflecting on the product, and refining existing code.

This is spending time and money on tasks that have no visible output, so it is key that a product owner has good communication with the development team, as well as the business team and stakeholders.

Technical Debt is just that, a cost your team will have to pay at some point – paying it early saves money down the line.