The intrinsic problems of software

During the last year I've seen a lot of people claiming against AI because it's not able to maintain the code, or the code is a mess or features have been lost. Welcome to software!!

One of the interesting things that AI is having is that it exacerbates software problems. I mean, I think a lot of people thought that the only problem in software was coding, welcome to reality it’s not.

There were another group of people that though that the rest of software problems were related to our nature, we are human so imperfects, etc.
The fact is that there are problems related to software itself that cannot be solved by a machine, even if the machine is able to rewrite everything in minutes.
Those problems are intrinsic to software.

How to update a running document continuously?

Let’s think about software as a book, a book that never ends to be written. So the book is updated continuously in new features, removing sections, adding new ones, etc.

People are continuously reading the book, imagine that you have something wrong, what changed since the last time you read it, how do you know what’s that delta.
Who wrote the things that are wrong, when, why?

All these three questions that are not related at all with writing code are solved right now in software by control version systems and practices that help us to identify who, when and why they did those changes.

So even if we have AI agents making changes in our code continuously we will need to understand who, when and why those changes were done.
If not, we will lose completely the control of the code.

The industry knows how to solve this, it’s called Continuous Integration.

How to know that there is a bug?

Lets for a moment think that we have the best AI, that’s so good and fast that we don’t need to maintain at all the code. It will be able to traduce from human language to machine code in minutes, building the whole app as we go.

How are we going to know that it builds the same thing as before but adding this small new feature?.

What is helping us to understand it?

You could say, there will be someone checking, but remember there is no high level code, it’s only machine code.
Our only possibility are tests, automatic or manual tests. But if you tell me it seems stupid to automatize the coding but waiting until one person checks all the scenarios of a big application until we go release it to our users.

Then it seems we need something to test automatically the application, something written somewhere to maintain the behaviors we want to maintain in each iteration of the application.

Right now we solve that with automatic tests, but wait automatic tests are code, if this needs to be the truth of our behaviors need to be maintained as code. It seems a circle, we will still need to maintain code in a high level language.

How to know what problem to solve?

How to know what the client needs?. This quote that people assign to Henry Ford, it seems he never said that.

“If I had asked people what they wanted, they would have said faster horses.”

Illustrate the problem itself, asking people is not enough, we need to create experiments and probe them in front of customers, this is in fact innovation.

User stories, vertical slicing, small steps are our current solution to this. Iterate with feedback from clients as fast as we go.

Clients are people, if you don’t iterate faster in front of them, how are you going to know if you go in a good direction or not?.

What are the bottlenecks in my path to production?

We tend to think that the bottleneck in software in our organization is coding, but it’s usually false. We think it’s coding just because it’s the time you need to put white over black, what is needed to explain a machine how to solve a problem.

The lack of knowledge about what we want to do is in fact in my opinion the usual bottleneck.
I’ve had the luck of being part of some teams that were so fast developing that there were no new user stories, features to do.
It’s a symptom of a suboptimal process in the company organization, just it was shown that when coding is not the bottleneck the next one is shown, that is usually why coding is the bottleneck.
If you want to understand your bottlenecks in your path to production, take a look to this article:

Amdahl’s Law

Amdahl’s Law is a fundamental principle in computer science that determines the theoretical maximum speedup an application can achieve by improving a portion of its system, such as using multiple processors for parallel computing.

The core takeaway is that speedup is limited by the sequential (non-parallelizable) portion of a task. No matter how much you optimize the parallel part or how many processors you add, the time spent on the sequential part remains the bottleneck.

Just consider your path to production as a system where Amdahl’s law applies, what do you think is going to be the result if you just improve the speed of coding to almost cero?.

Small steps

A lot of people claim against AI because they asked the genie to create a big thing that worked perfectly fine, but the code design was garbage. They realized this later when they wanted to introduce a new feature.
I’ve seen this in the past, people throwing code with no care until the cost of adding a new feature is so high that we rebuild everything.

Big ball

of mud, the most used architecture in the world, is the clear example that we suck as AI sucks writing code.
To avoid this, we need to work in smaller steps, refactoring continuously the code, understanding what we are doing and why we are doing it in that way.
Small steps always warranty better solutions.

Then to solve this, we changed our minds and we start thinking that pairing with the machine is the solution, working with it instead of leaving it alone.
So people claim I need to create better prompts, in fact you need to learn how to pair.

Trust in the machine, but lack of trust in people

We are fascinating beings. We trust a lot in the machine, but not in people.
The normal process working with AI that I’ve seen is integrated in an IDE that helps to answer questions or create code.
We ask the genie to create a change, and it does, we take a look, and we include in our local machine.
Where are the PR’s in this process, why do we so care about what people do vs what the machine does?.

In fact, we know that actual AIs should be considered like a junior dev you have to teach things.

When you are pairing with AI you are basically doing Trunk Based Development, why are you doing that, because you are pairing, and you are trying always to do right things.

AI is great for helping devs to code, for improving the time if we know how to use it. But it’s not solving the intrinsic problems of software.