AI is the new Outsourcing

Repeating the same mistakes is not innovative

Under the guise of being a “revolutionary technology”, AI is used to maintain worldviews from more than a century ago. Keeping alive legacy thinking is hardly going to build a better future.

I had a colleague who was very experienced in calling out BS (business speak). He had a lot of experience, he had seen enough in his life, he did not care whether his remarks made him popular (which made him very popular). He had little tolerance for being fooled with new and shiny concepts. Every time someone would try to impress the audience with “the next big thing”, he would ask very calmly: “What is new here? I have seen this all before!” Interestingly enough, many proposals failed this simple test. What a way to call out smoke and mirrors!

This is a great attitude and behavior. I took it as an example. Let’s try this surprisingly effective approach on a topic where it seems to be impossible to bring in any reason at the moment: Artificial Intelligence (AI).

It would be impossible to point out every eye-rolling occasion I go through, and the topic is already tiring enough. Therefore, I picked two articles by Stefan Wolpers from Age of Product about “Write As Little Code As Possible” and “When Code Is Cheap, Discipline Must Come from Somewhere Else”.

I highly respect Stefan Wolpers. He is one of the people from the Agile community who inspire me. Just today I recommended his book “The Scrum Anti-Patterns Guide” to a colleague. It made me laugh out loud every ten pages while reading.

So the following criticism is not about the author — not even about the points presented. It is about the assumed or real world view of the people who are the target audience of the advice provided in these articles.

The exact story keeps slowly changing over time, but the gist remains the same: AI can provide software that passes tests also created by applying AI and be deployed on production with a fraction of the time and money that used to be spent on software developers. But then — surprise, surprise! — all kinds of problems come up: The software does not solve the original problem. Nobody understands what it does. Security issues are detected. It fails regarding some of the typical non-functional requirements (the -ility collection). What to do now? How to handle that?

Now first, as an experiment, replace “AI” in this story with “Outsourcing to countries where labor is cheap”. How fresh and new does it sound now? It seems all too familiar to me. Fantasies about replacing decently-paid and fairly treated Tech people with armies of coders in low-cost countries and still have a quality product and viable business have existed long before. So the current craze about AI is obviously not about technology but being cheap under a new packaging. Unfortunately, your system will break where you go cheap. Even worse, many other antipatterns that plague software development are included as well!

First, slow speed or high cost as a protection mechanism against waste were always an illusion. Instead, slow speed by too much bureaucracy, too much control ensured that most of the time, you were building the wrong thing, because by the time you were done, the world had moved on. Money is not a costly signal. A lot of useless stuff still gets built even when it costs a lot (think of pet projects and office politics). Plus, a lot of stuff that cannot be built is still attempted to be built. And even if you can built them, most features are rarely or never used. Those truths existed long before AI. And they have still not been learned.

Second, the idea that you speed up one specific part of the whole value creation and then experience massive gains in the overall workflow is a basic non-understanding of Systems Thinking / Flow Thinking. I have stopped counting the labels and authors where I saw this idea being expressed. It has been around for decades, ready to be grabbed and applied. In contrast to this, it appears that AI is used as a last measure to uphold legacy thinking:

The old cost-center view on software development, sequential thinking, Tech people as factory workers… in other words, signs that reveal that someone never really understood software development (or had empathy with IT people). AI (and outsourcing) present the world as non-Tech people see it and think it should be — not as it is actually working (as least effectively). This also means that saying what is true will also not convince anyone, as it challenges dearly held beliefs (and fears). (In other words, I have no illusion that an article like this one might change anyone’s opinion. If people want to listen, there are plenty of sources out there!)

Third, do not get distracted by agile strawman arguments about Code Reviews, Daily Scrums, Sprint Reviews or Refinements as crucial opportunities to stop and think. Code Reviews are very likely to be highly wasteful (thanks, James Birnie!). Daily Scrums are about checking progress towards a shared goal. Sprint Reviews are about inspecting together what has been achieved and deciding what to do next. Refinements can be productive conversations to gain a shared understanding about what needs to happen (and can also be highly wasteful). They are not meant to be a more fancier form of gateways or approval stages. That is not their purpose, and if they are used like that, something else is wrong! This would also be reversing the argument that only by putting something in the hands of the users, you see what is valuable.

It is the overall flow that counts, and AI taking care of one small part but not improving the overall system is not a success. Even worse, it is a regression from good engineering principles: Instead of “shift left” principles (care about it/build it in as early as possible), suddenly low-quality, low-fidelity code is allowed to go all the way down to production. As Deming said, you cannot test in quality. (You might also question the statement that “the code worked” when it introduces security vulnerabilities. Well, it did obviously not pass NFR tests, or automatic checks done by tools like SonarQube! Technically shippable does not equal shippable from a quality perspective. Effectively, you are not shipping faster, only passing specific points in time faster.)

We see a revival of the old and wrong trade-off between speed and quality. AI is being used to eliminate pushback from software developers — the AI won’t argue with you — at the cost of throwing quality out of the window. We seem to regress from quality to quantity (lines of codes, number of commits) as a measure of success. On a side note, all the hard fights to get usability into the mix are also rolled back.

So, what’s new? Even less. As another good colleague used to say, the lazy software developer is a good software developer. Do not do more work than is strictly necessary. Or as the Agile Manifesto puts it: “Simplicity — the art of maximizing the amount of work not done — is essential.” The lesson has been there for decades. I am not optimistic that it will be heard this time.

You might argue about the term “strictly necessary”. Doesn’t this mean throwing quality over board as well? Well, I know what a good software developer was like 30 years ago. There are professional standards. These have evolved but overall they have aged pretty well. How could we ever allow the image of our profession to degenerate into order-taking code monkeys?

Any attempt to lower this bar is for me moving the goalpost: Software development was always more than coding, “is deployed” is only a fraction of “is actually working”.

The perceived “progress” consists of only shifting what is difficult: code that somehow does something and appears to do what you want it to do. All the other usual questions are still in place: Who maintains the automation? Who owns this on the long run? Who takes care of it? Who can debug it? There is little value in the happy path.

What is new, and that I admit has some value, is the different form of rapid prototyping. “How could this look and feel like” can be answered amazingly fast. It is still no proof that this would actually work or be performant, NFR-fulfilling software, but less imagination is necessary to picture an idea.

For the rest, have no illusions: The real constraint of software development is that you still need a human who understands what is going on (and is accountable for it).

Yes: I’ve Seen All Good People: a. Your Move, b. All Good People

[embed]https://www.youtube.com/watch?v=vD_NbztLhpU