Building hardy software applications

A small plant sprouting from a hard, sandy surface

We take the responsibility to provide the most value possible to our clients very seriously.

We want to build applications that are long-lived (lasting 10 or more years). We want to build applications that are hardy.

A hardy application is built by people who recognise that it may be just one application of many which are important to run your business.

Your business will certainly evolve over 10 years. A hardy application can survive periods of relatively low attention from your organisation and still remain cost effective to change and improve when/if your attention returns to it.

A hardy application will thrive on attention. Teams can be spun up, and features added quickly if necessary.

A hardy application is an investment, not a liability.

The only reason a hardy application should be retired is that the business need it was filling is no longer required. Hardy applications do not need to be re-written.

What does it take to make a hardy application?

Business priorities change over time. Some applications remain core to your business, but many apps in your stable will sit there doing their job and getting infrequent updates. Hardy apps survive long periods where the focus of your organisation is elsewhere.

Over the years, we have boiled down our strategies for building hardy applications to four key ideas:

  1. Have an automated test suite that we can trust
  2. Have a maintenance plan
  3. Choose technologies with both a history and a future
  4. Plan for when nobody remembers

1. Having an automated test suite that we can trust

A trustworthy automated test suite is non-negotiable for us. It is the difference between an app being an investment or a liability.

An automated test suite is a way to express a set of “When X happens, the application should do Y” checks in code so that they can be quickly and cheaply run in the future.

A test suite is trustworthy if the team can make arbitrary changes to the application and be confident that the tests will catch any inadvertent errors introduced.

An incomplete automated test suite is still useful, but most of the benefits are unlocked only when the team can trust that the test suite covers all the important use-cases in the application.

When an application is under active development, an automated test suite improves software testing efficiency and accuracy, allowing the team to make changes quickly while retaining safety. Trustworthy automated tests are the (often unstated) entry requirement for all modern “deploy faster and more often” devops practices.

When an application is no longer under active development, the trustworthy automated test suite is arguably even more important. This is because it encodes knowledge of the application that no one in your organisation now remembers, while the application remains as reliable as ever.

2. Have a maintenance plan

Bespoke software requires maintenance.

We build with maintenance in mind. We maintain most of the applications we build for clients and have done so for over 10 years. This has created a virtuous cycle where our developer teams are strongly connected to the operational impact of their choices.

Some technology choices provide a strong initial win but can be expensive to keep patched and updated. In the worst cases, a full rewrite of portions of the app may be required to keep an application patched and secure.

At minimum, you should expect to need ad-hoc security patching throughout the year and a once per year framework upgrade. The update cadence of different frameworks and languages varies, but in our experience a yearly upgrade cadence is the right balance of staying secure and managing costs for most applications.

Some of our clients handle this in-house, and we take care of it for others. Either way, somebody needs to do this. Without a maintenance plan, the app will not survive periods of low attention from your organisation.

3. Choose technologies with both a history and a future

Apps that live 10-plus years need to be built on a technology stack which will live at least that long.

We believe the way to do this is to choose technologies with both a history and a future.

Mature technologies are ones where both the advantages and the warts are understood. Developers and operations people have had time to build up expertise and learn what works well in theory vs. what works in practice.

Just being mature is not enough. A technology must be maintained and have a future – an active community or vendor. Ideally other high-stakes apps which are running in production also depend on this technology.

There can be situations where a newer, as yet unproven, technology is the right choice – this is discussed in more detail below. We will not hesitate to suggest these technologies if we see sufficient advantages but will discuss the risks and rewards of the choice with you.

4. Plan for when nobody remembers

Eventually none of the original team will still be working on the application. This is almost guaranteed for a long-lived application. In fact, we maintain a number of apps for clients where nobody on the client side remembers how it works.

In this situation, good documentation is important but a good automated test suite is vital.

Choosing technologies which are still active and maintained is also vital. If the new team does not understand the technology then an expensive rewrite is the likely outcome.

Context is king – prioritising a hardy build is not always the right choice

Prioritising a hardy 10+ year app is not always the right approach. Context is king and each client and business problem is unique.

For example, start-ups and other situations where the business problem is not yet well understood requires us to re-order our priorities – to bend the rules, so to speak. So which rules are bendable?

Having an automated test suite is a hard rule and is not bendable. Automated test suites are even more important in fast paced environments because they allow us to add features quickly while being confident that we are not breaking existing functionality, even if that existing functionality itself has only been in the app for a short period of time. Never trade away your trusty automated test suite. If you are working with us, we won’t even put this on the table for discussion.

If an app will be constantly worked on, for example the main app of a start-up, then having a separate maintenance plan isn’t as crucial because the dev team can take care of those tasks as part of their normal development work.

Sometimes it makes sense to choose technologies which are newer or ‘riskier’ because they can provide a unique advantage to your business, such as differentiating you in the market. If you are working with us, we will discuss tech choices at the start of the project to make sure we make the trade-offs together.

Want to work with Ackama on hardy applications?

Ackama are always excited to speak to people as passionate as we are about building powerful digital tools, and organisations who we can help realise projects and goals.

View current open positionsTalk to us about your future project