Two truths of software development still valid in the age of AI
«Everyone» uses AI for coding, at least that’s what people on stages and in social media wants you to believe. It is a train we all need to get on in order to not be left at the station. Developer relations folks from the tech monopolies are spreading a message of fear, where you get on or become unemployable. They serve up images of the infamous “COBOL developer” (who by the way most likely make more money than most, and in general has significant leverage since their skills are rare to come by), saying this will be you if you don’t get onboard now. Organizations and people alike hear the scary tales and nobody wants to be against “progress”, so we jump onto the train hoping it ends up where we want to.
The promise of tools enabling people with no programming skills has been around for a long while. A professor at Molde College in 1996 said that we were thought Java and C++ as a curiosity, as by the time we were done studying, 4th generation programming languages would have taken over. These were tools which we would call “low code” today. Needless to say, my professors predictions did not quite pan out. Later I was exposed to RUP (Rational Unified Process) which provided a method for generated applications based on models often times in the form of UML diagrams. By modelling use cases and process, a developer would simply generate programs. It did not quite pan out as its proponents hoped and it never became a wide spread approach. There has been numerous attempts at removing the programming from software development, none of them has yet been successful.
The age of AI generated code is upon us with the value propositions being more or less the same as those of days gone by. Efficiency, reduced need for skilled laborers and improved speed of development and innovation. This latest generation of tools is better than what came before them. However, its proposed value lays bare a lack of understanding of what a software systems is and what it means to build one.
After more than four decades of software development there are some truths which have emerged which applies:
- when we start, we don’t know what to build
- it’s never done
These facts form the foundation of most modern software development practices. AI tooling helps with none of these things, not even if your use case is «I just need an App».
Context matters
As with most things context matters, and it certainly is importantly when it comes to where and who are passionate advocates for things like AI as an assistant to writing code.
If your objective is to do as little work as possible for the maximum amount of billable hours, then AI is perfect. It can help you scaffold up something, enabling you to have lazy days while the bill rises to the agreed price. It’s not a coincidence that the consultant industry is pushing AI, as it makes their jobs easier. Their clients, will be paying in more ways than one.
If you have no coding ability and need to show you idea, then AI is an enabling tool. It’s also cheaper and easier than hiring developers, as we know hiring developers is very difficult if you are not a technical person yourself. In this scenario, AI is a key enabler.
What I am talking about in this article is related to people developing software for a living in a professional settings.
Learning #1: we don’t know what to build
The dogma would counter this argument with the obvious: «You would use AI to assist you in figuring this out». Again we see a flawed concept of what developing software is, as the most important thing is the very exercise of figuring this out. Thoroughly experiments, studies, analysis,etc we gradually build out a mental model of what to build. This is the actual deliverable of a software project: a mental model of how to automate something.
The implementation is an artifact from this process. Both the deliverable and the artifact are subject to change and is thereby never done.
If the knowledge lies in the prompts sent to different models, you will as time passes realize all you have left are empty artifacts without the knowledge that went into them. Similar to how archaeologists try to reconstruct history based on artifacts they find.
One could argue that you can get the best of both worlds, where you somehow save the knowledge going into the prompts. The issue here is that even with that, you have no idea what happened in the box to make the outcomes you have in front of you. You are left with hollow artifacts and you most likely are better off just starting again from scratch. A «Las Vegas Way of Working» with software, where you blow up buildings and rebuild something new in its place.
Learning #2: it’s never done
Expanding on what was discussed in Learning #1, this section is about the context, time and how we preserve knowledge. I claimed that you are left with artifacts after some time if you base you work on the automation of AI (where AI is the current most relevant example. Twenty years ago it was 4Gen development tools).
Once you write the first statement of a program you have created something which, if it’s usable, will require your attention over time. This is where
some old folks come in and say «What about Fortran / Cobol / some other old programming language?», where the idea being that somehow these systems were written and wasn’t subject to changes, update or maintenance.
This argument is valid only if you see it in a short time span. I once worked in a Norwegian bank where they had found a program which was running on Wang and written in XXX. Nobody really knew what this program did, but it was used in a chain of calls essential to some critical operations for the bank. They’d tried to by pass it, only to see the operation fail. They were left with a dilemma. The program was brilliant and so was the infrastructure, however there was only one person left with knowledge of the operating system and the programming language. This person was approaching retirement, which meant they were in a pickle. They had to figure out what the program did and rewrite it before this individual ended their time in their bodily vessel.
In conclusion: all software requires up keep, some more than others of course.
Accepting that all software development efforts never end, maintenance and evolving / changing is a critical aspect of the work. The believers of AI would say, even if our current AIs can’t, the future ones will be able to as it’s inevitable that they will just get better (exactly how, is a bit vague). I guess we will see.
In closing
If the evangelists of AI are correct many of today’s software developers will be merely code reviewers and analysts in the future. This is the only thing I fear as a software developer, that my job will become incredibly boring and mundane without any creative element involved. It will be like supervising an assembly line of robots making a car.