Can Developers Reduce Software TCO With AI?

Long gone are the days when you would buy a Nintendo cartridge and never update the software on it. The world has changed, and so has software. 

Instead of living in its own tiny (awesome) gray and black box, software is living on interconnected machines. It has to react to change; it has to adapt and for different reasons. Whether it's a security update in the face of a new attack or a feature update to keep up in this changing ecosystem. Software has to be updated; it has to be maintained. Code has to be rewritten, dependencies have to be updated, applications have to be redeployed. 

This is not free. There is an ongoing cost to keep it deployed so that it keeps providing value. And the more code you have to maintain, the higher the cost, which is why code is often deleted. Now the question is: Why would you delete code that provided value? Where is the value in code?

Evolution of Code and the Development Ecosystem

To understand the value of code, we need to talk about abstraction. Most developers don't code with 0 and 1, or even from 0 to f (some still do). Instead, programming languages have evolved to allow developers to use actual words instead of 0 and 1. Hardware has evolved to abstract in silicium what developers would have had to write. Programming languages have evolved over time, and they keep evolving into higher levels of abstraction to make developers’ lives easier. We went from low-level machine languages (first-generation language or 1GL) to assembly (second-generation or 2GL) to more abstracted high-level languages (3GL) like C or Java to more domain-specific languages (4GL) like R, SQL or PL/SQL to constraints/logic-based languages (5GL) like Lisp, OPS5 or Mercury. The point is each generation abstracts more complexity from the developer. 5GLs are relying on AI to create solvers based on stated problems and conditions.

Development ecosystems have evolved in lockstep with programming languages. Devs don't start from scratch when starting a new project. They use libraries, dependencies, databases, data platforms, no code/low code. They use and interact with existing software. Anything that will abstract code, anything meaning that in the end, they keep providing the same level of features with less written code.

Lowering Total Cost of Ownership (TCO) and Improving Maintenance 

Starting from scratch would be prohibitively expensive. I always remember this toaster story. Thomas Thwaites decided to create a toaster from scratch without any of our existing abstractions. He made everything himself, from mining ore to smelting it to everything else you need to do to build a toaster. In the end, the toaster did not work and cost an absurd amount of time and money. It takes an entire civilization to build a toaster. Software is the same (although we might not be at that point yet). If you want to provide value, you use abstractions. Less code written means less code to maintain, resulting in less money to spend maintaining it, which means lower TCO.

The job of a developer is to write “legacy” code. If you have legacy code still running somewhere, congratulations, you have provided and keep providing value. One of the best ways to do that is to choose your ecosystem of tools and dependencies or your abstractions wisely. Using a modern cloud data platform that supports multiple kinds of workloads and keeps proposing new ones is a good bet. Because changing databases along the way is costly, it's not so much about moving the data; it's about rewriting the code and maintaining new things. And we all know now that the more code you write, the higher the maintenance cost.

AI’s Impact on Software Development

What does it have to do with AI? There has been much excitement for large language models (LLMs), and we saw new tools popping up and promising to write code for you. While this might reduce the initial cost of software development, is this really what developers/organizations/teams want? What is the cost of having more code written that may or may not do exactly what we asked for that has not been written by anyone on the team? How challenging would this be to maintain when it could have been abstracted by the right tool, the right library? How expensive will that thing become?

Consider that code generative AI are technical debt generators for 3GL, for now. This may change in the future as it gets more accurate and gets better at using existing abstractions and surrounding ecosystems. But right now, it's not generating added value; it's the opposite. You have as many ways of writing Scala code than you have Scala developers (with 3GL, you would be generating a lot of “glue” or boilerplate code – code that helps interfacing the abstractions you are using, or even that replace what could/should have been another abstraction, another dependency). 

Right now, it's more interesting to look at existing 5GL or to use generative AI for 4GL, especially domain-constraint ones like SQL. SQL is a great fit for generative AI because the syntax is simpler. SQL is SQL. You don’t need to maintain SQL code as much as you would with 3GL. And when generating SQL code, the value is directly domain value, business value. That’s the most important bit. SQL is the sweet spot between 3GL and 5GL. It’s still a programming language like 3GL. You can still express what you want instead of the problems and constraints you have like you would with 5GL. There is a reason why every data store out there ends up bringing back SQL. And why SQL keeps being updated with new features like we are doing at Couchbase.

Conclusion

If you are looking at reducing your TCO, choose the right abstractions. And if you are looking for generative AI to reduce your TCO by writing code for you, think twice and make sure you use it with 4GL.