This week we’re talking about the second section of the EndGame technical manifesto:

‍

“Build client driven, long-lived solutions, that are both sturdy and maintainable.”

‍

When I stood at the foot of this ziggurat (shown above) I was amazed at the craftsmanship of an ancient people. And given that it was after the end of the Mayan calendar, I had another thought:

Did the craftspeople who built this ever expect these buildings to last this long?

I’ve had the privilege to visit many other ancient sites and this thought always occurs to me.

When you build a business, you expect it will last for a while. Therefore it stands to reason that the core business software that you’ve built will also need to last.

Core business software for companies (that aren’t selling software itself) is usually about modelling a process that already exists in the business — to drive efficiency into that process. Not much thought is given to the idea that the process will change in time as the company grows and pivots.

We must build long-lasting software for business that’s able to be adapted as the business changes. And we must do this without being too generic — as that leads to the loss of efficiencies gained by software. Yet, it mustn’t be so myopic in its approach that it can’t change as the business needs it to.

The counter point to this is that the people that commissioned the ziggurats didn’t expect their buildings to last this long. They wanted to rebuild them, but things just got in the way.

This is a common theme when we’re working with green field ideas. The concept is always to build fast and then, in the future, we’ll rebuild it.

I’ve found though that a successful idea very rarely gets this luxury. It will slowly be built on, improved and refactored — but never really “rebuilt”. And unsuccessful ideas are discarded. Or worse, are just useful enough to keep around but not successful enough to maintain.

It’s not our vision to create solutions that don’t last. But rather create solutions of worth that are here for the long haul. Though it may be a little ambitious of us to hope that people in 500 years will be able to stare at it in wonder!

The reason that long-lived is an explicit part of our manifesto is because it must influence the decisions that are made to provide a solution. If it wasn’t for the idea of longevity, then the following points of Sturdy and Maintainable don’t make sense. They are in fact superfluous without it.

A solution doesn’t need to be Maintainable if it’s going to be thrown away — spending time maintaining it would simply be time wasted. The same can be said of Sturdy. While the solution needs to be stable while it’s alive, the cost of support (in the end) is always based on the time you need to support it.

Which brings us to another reason that long-lived is part of our manifesto.

Solutions are always going to last longer than you planned. So while the customer may be thinking ‘it’s an alpha version and we’ll throw it away after investment’ — we should realise that this is never true. And in fact is a bad idea. That’s why we should always be looking to build something long-lasting.

Long-lived is part of EndGame’s manifesto because it’s a fact of core business software. And we, as a long-term software partner, need to be building and supporting long-lived software for all our clients.

‍