If you’re a developer, it’s pretty easy to create a simple new web application. It’s much harder to maintain it over time, and ensure that others can take over its management and development with minimal disruption. Now we get to the impossible: how do you build a system that non-technical people can manage and sustain? How can we avoid creating so much complexity that it requires excessive amounts of skill and knowledge to deal with? It’s hard to make complicated things simple, and those that do are usually the ones with excessive (and expensive) skill and knowledge.
A common approach is to set up an SEP field around it. This is also referred to as outsourcing. This can be quite workable, but it’s likely to involve mediocre-quality, off-the-shelf, one-size-fits-all solutions that nobody really likes, leading to apathy, stagnation, and the loss of institutional knowledge of what the thing was built for in the first place. It probably won’t cost too much, but its bills will continue to accrue amongst the stacks of paper in the accounting department long after it ceases to be useful, and nobody wants to stop paying because they don’t know what will break if it gets turned off. If the service you’ve outsourced to shuts down unexpectedly, you’re likely to lose everything entrusted to it.
Contrary to what you might think, developers love simple things
A common approach to sustainability is to make sure we use simple, standardised tools that provide just enough expressiveness and clarity to get the job done without overcomplicating it. Contrary to what you might think, developers love simple things – minimal special-purpose languages like YAML and Markdown have become enormously popular, often indirectly replacing more complex formats such as MS Word, HTML and XML. Concepts such as “serverless” computing allow you to deploy large-scale applications without having to know or care about the systems it’s running on. There’s an element of SEP about that, and the reality (that it’s not actually serverless at all!) occasionally peeps out.
If you’re going to have a system that actually does something useful in some automated way, you’re going to need to do some programming of one kind or another. Programming can be defined as the task of bridging the conceptual gap between what you want and how you say what you want with sufficient precision. While visual programming languages like Scratch and Node Red can avoid much of the fear of arcane syntax, ultimately you still have to decide what you want to happen to which things, and when. That doesn’t go away just because you’re dragging lines between boxes instead of typing text; they’re really just variations on the how you say theme. There’s an old joke about how you’ll always need programmers because nobody commissioning a technology project can express what they actually want with sufficient accuracy in the first place.
Receiving, storing, transforming, and generating data in its myriad forms are what all these tools are for, and fortunately both we and technology are getting better at it all the time. A key accelerating factor is that we’ve reached a point where we can get the machines to do some of the work. After much over-promising and under-delivering in the 90s and 00s, machine learning and artificial intelligence are becoming genuinely useful, but we’re still at the “iron dovetail” stage. Our ineptitude with these new tools is often evident, but at least we are aware of it. So long as we’re on top of it all before the singularity hits, all will be cool 😰.
So what can we do to keep sites and services working with minimal dependence on continuous financial and technical support? For the most part, simplicity is the answer; complexity costs both time and money. Straightforward approaches to basic operations should be given top priority. On the other hand, a balance needs to be struck. Some complexity is necessary – something that’s too simple probably isn’t that useful either; computers are supposed to make difficult things simpler, or at least faster!
A different approach is to get someone else to pay for it! Instead of building (expensively) something that’s exclusively for you, design something that’s useful to you, and also to others like you. Once you’re in that position, others in the same boat might look to pool resources, share costs, spread the load. There is a whole world of open-source software available for this – many of the things we build today are only possible because of the vast library of open-source starting points, frameworks, components, and tools.
For now, web developers have to fulfil this wizard-like role of “translator of wants” into the inscrutable dialects of modern programming languages while trying to keep costs and consumption to a minimum. One day we might be able to get an AI system to do what we want; we just have to figure out exactly what that is and how to ask for it.