Why do software craftspeople create better, more resilient code ? i.e. code that is just better for business continuity

IIn the continuation of my thoughts on the "...ilities" series i.e. the non logical and non functional aspects of the software systems that we collectively put together I posed myself the question, "Why is it that systems designed, built and maintained by software craftspeople are much more resilient, more adaptable, more capable of handling and dealing with business threatening problems?"

There are obvious levels of surviving a business continuity problem that are beyond almost anyone to cope with, i.e. volcanoes, bombs, floods, fires, mass hysteria, cats and dogs living together.... you get the point.

I personally experienced being a software developer at an inter-dealer broker in the City of London in 1992 and we had two IRA bombs within a few months of each other that fairly well destroyed the building we were working in. This is why you have a disaster recovery plan after all.

But, in between an Armageddon event and an annoying UI bug there are many, many things in between which will not surface on the radar as a serious continuity problem specifically and therefore are generally never planned for in a business continuity plan.

But they do happen and they happen more often than you might like to think i.e. they are not a big disaster per se ... BUT they can still be an existential problem for your business. Precisely because they were not thought to "big" enough problems to worry about, or that it would be something what would ever realistically happen.

For example what if the API you rely upon to issue direct debits to your customers fails because they released a new version and it broke - bad dobby!

Your business then won't be able to charge your customers, you might be ok for a few days.. but what if this API you rely on was out for a week, 2 weeks? or perhaps the supplier company goes completely into administration and you, like most startups, don't have much leeway in the runway to cope and you now have a massive cash flow problem that just might kill your business too.

This sort of situation happens way more often than you might think. For example a scenario I experienced in Australia when RailsR exited the ASIA-Pac region in March 2023 anybody who used RailsR was left without a card processor and just a few months in which to find a new supplier, re establish new APIs, new processes, new cards, transferring balances from the old system to the new system seamlessly. This is when you need your code, your systems, your application to have been architected and built by software craftspeople from the get go.

Because, for a craftsperson it is not enough just to “make it work”, it's also not enough to “make it maintainable or understandable”, they also architect and strive to surface to the business owner/product owner/founder/SLT that in using other APIS, other systems, other cloud platforms and other providers that every aspect of our business is then bound up with how well somebody else has architected and supported the systems that we are relying on.

As Craftspeople who are concerned about the system we have created we take time to understand, where can our system break?, what are the single points of failure in this overall system? How will we survive if X dies? The Craftsperson designs and builds the architecture to allow for this need. They have already made the code understandable, readable, maintainable, adaptable, testable and deployable which means that they already have an environment and are in the best possible place in which they are able to respond to this situation.

They will have created a strong separation of concerns, with loose coupling between systems, encapsulation of that which changes with isolated classes, with everything segregated by interfaces, the use of design patterns such as facades, bridges, routable message queues, command and control methods that allow for and handle failure gracefully, minimized accidental complexity and created defensive code that copes with bad values and things not being in the state that is expected. Code that automatically detects and heals bad data.

This creates systems where a failure in a single system is isolated, handled and the rest of the system continues to work. A system whereby a change to a major component of the entire system does not affect the entire system, because the craftsperson will have encapsulated that which changes giving the ability to switch out provider A with provider B quickly, being able to build, test and deploy very quickly once the solution is arrived at.

If you have had the luxury of giving your craftsperson team the budget to have fall back APIs, fall back providers and suppliers, you may even find that the code is built and deployed faster than you can tell customers about the potential upcoming problem.

The software craftsmanship attitude and ideologies address this need of delivering continuity to a business. The software craftsmanship community is well aware of the need for better business continuity and they are very well placed to provide solutions to these problems

Remember....

Software Craftsmanship = Better Code

Better Code = Better Business.

Regards Julian