This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub

AI as a Mirror — a Conversation with Kevlin Henney

A note from our team.

Software-Architektur im Stream will be streaming live from the ISAQB Software Architecture Gathering in Berlin this November.

Join us on site.

You’ll find more about the program and special discount code for our community on our website software-architektur.tv.

Hello and welcome to another episode of Software-Architektur im Stream.

It’s hard to pronounce German in an English sentence.

Yeah, I think it’s my first episode which I moderate in English, and we have a special guest.

We have Kevlin Henney with us.

Kevlin, is it OK if I ask you to introduce yourself?

Of course, Ralf, yes.

And I can do a better job of that in English than I could in German.

Let’s put it that way.

So, yeah, my name is Kevlin Henney.

I am an independent consultant, speaker, trainer, writer, thought guy.

I like to, you know, these days I think I’ve reached a point where I just like, let’s explore ideas and play around with those as well.

I don’t think that’s a professional role, but I think it’s certainly something that I enjoy doing.

And I’m based in the UK.

I, as I say, I’m independent, so therefore I’m not affiliated with any company.

Sometimes this means good stuff in the sense that I can see different companies or, you know, either at the very minimal level of doing a talk, and sometimes I do some consultancy and get a little bit closer to things.

But it gives me a very different view, I guess, than than other people might get of what’s going on in software right now.

But again, I’m also guided by my interests on that.

So regarding your interests, we just talked a little bit about your bookshelf and that you have, yeah, written a lot of things.

And could it be that you started the 97 Things series, 97 Things Every Java Developer Should Know, something like this?

Yeah, the 97 Things series started back in the 2000s, towards 2010.

And it was a guy called Richard Monson-Hafel originally started with the first book, 97 Things Every Software Architect Should Know.

And then I threw in the more, probably the most successful book in the series, 97 Things Every Programmer Should Know, which, and these books are basically crowdsourced, lots of contributors, and obviously 97 Things.

And normally they’re about two pages long, each recommendation or idea to explore.

And I found out a really fun project, it was kind of like open source code, but with words and concepts.

And that was that was very enjoyable.

And then just around the time of the pandemic, myself and Tricia G. did 97 Things Every Java Programmer Should Know.

And I’ve recently been thinking about maybe doing another 97 Things book, but maybe that will come up in conversation.

We’ll see how this one goes.

So I jotted down a starter question, which was, let’s start easy, your favorite programming language, you just noticed Java, is it still your favorite language?

I don’t know that.

That actually, I think that is the best question.

Do I still have a favorite programming language?

I think when I was younger, it was far more important to have a favorite programming language, like having a favorite band or something like that, you know.

But I also learned something else is I’m really bad with these questions.

When somebody asked me, what is your favorite one of these?

It’s just like, I can never pick one because I know that what will happen is it changes on a, it can even change within a day, but it changes on my mood or what I’ve just been doing.

Okay.

And so I guess I have a bunch of things that statistically, I could work out whether or not something is a favorite.

And no, I don’t think Java is currently my favorite.

It’s not, I don’t feel as engaged with it at the moment.

I haven’t really done much Java this year.

Probably if I do it by what programming language have I used the most this year?

I think it might be Python, statistically speaking, if we looked at it from that point of view.

Although I’ve done a fair amount, I think I’ve reached my end of C sharp and been doing a bunch of C++ with bits of C.

So yeah, you know, yeah, I don’t necessarily play favorites, although there are languages that I definitely dislike.

I find it harder to say which at the top of the stack are the ones that I really like.

And if you ask me when I’m playing around with something and it’s working, then that’s probably my favorite language.

If I’m playing around with something and it’s not working, then that’s not my favorite language.

You know, it’s a very emotional and time-based judgment.

Do you still write code yourself?

Yes, I do.

Yes.

I, well, I’m currently not working on any major projects or doing anything production-oriented.

So most of the code I write is small fragments.

And so I, you know, small fragments and experiments.

So some things I’m going to generate, some things I’m going to write myself because I then know what I, the scale that I’m writing, the scale I’m dealing with, it’s just like sometimes I do it because I enjoy it.

You know, it’s as simple as that.

At other times, it’s a case of like, I’m being a little more, I guess, functional and practical.

It’s just like, oh, I’ve got this, let’s generate this.

And then just see if that’s the right thing for whatever we mean by right at this point in time, play around with it, adjust it.

Or if I discover this is way off base, either I need to change how I’m specifying this, or actually I now understand what it is that I want to write.

It will take me less time to get it right than it will to poke and prod an LLM to get it right.

So the point is that, yeah, I do.

And I also make, I do make a point of working with the code at the level that I’m working because it’s at, as sometimes it takes more time to do it via an LLM exclusively.

So I admit it’s kind of more mixed mode.

And yeah, in that sense, I guess a more hybridized way of working.

Before we dive deeper into coding and maybe also coding with an LLM, you influence lots of people.

I remember some talks where you talked about the shortcomings of the Java language.

But what influenced me myself most were your collection of software failures in the wild.

And every time I see some screen where the boot screen or something like this on an airport, I always think about, hey, that’s a Kevlin Henney.

Should I take a picture?

Should I send it to him?

Do you still collect those?

Yeah.

Yeah.

I mean, what I do is, so for those of you who are not aware of this, I mean, years ago, it was one of those things that I started taking photographs for which we can thank ultimately the integration of cameras into phones because obviously then you walk around with a camera everywhere.

And I started noticing errors.

And obviously, as more of our life and our public space is mediated by software-related devices, you’re going to get more errors.

And I started thinking these were kind of interesting because what for me was interesting about them, one, they’re kind of fun, but they show us where the real action is.

I think a lot of what companies do is actually not what we should be concentrating on in software development, which is why I sometimes take certain trends in software development to be, yay, brilliant.

We’re doing something, you know, we’re doing the wrong thing better now.

Rather than let’s do the right thing, we’re now going to do the wrong thing better.

And the point there is that we end up with frustration in many cases when we encounter software failure.

But so there’s a reminder, and I always framed it like this, is that whenever we see public failures, these are kind of like, I don’t know, they are installation art.

You know, it’s software developers without meaning to are the creators of the most accidental installation art on the planet.

You know, it’s just like, here is a screen.

And it’s kind of like, if you look at it through artistic lenses, it’s quite funny.

But at the same time, what I find, I also find interesting is that when something breaks, when something crashes, it reveals how it was built.

It shows you something about how it was built.

Maybe it’s a stack trace.

And previously, you would just, it was just a, you know, it was an information screen, perhaps in a shopping mall or something like that.

But then suddenly you see a stack trace and you realize, oh, at the back end, they’re using SQL Server.

At the, you know, at the front end, this is all, that’s JavaScript error and stuff like, in other words, you see the technology, and particularly in stack traces, you’ve got a shopping list, a manifest of everything that’s been done.

But also you see how it was developed.

In other words, you get a sense for what was tested and what was not tested.

So I find it’s interesting.

It’s like we have, in software development, ultimately what we do is we create an illusion.

We create an illusion of something perfect.

At this point in time, you know, everybody here is experiencing the illusion that we are kind of doing almost like a live studio, you know, old school.

This is a television.

Actually, it’s not a television in the traditional sense.

It is a computer pretending to be a television.

You know, we are pretending to do what was traditionally a television show, and we’ve taken that format into the modern age, the podcast era, and so on.

And we create this.

So my universal computing device is now behaving as a kind of like a talking heads device, if you like.

But if it crashes, then it loses that illusion.

It suddenly becomes something else, and we see how it was made.

So I, for me, there’s this fascination.

And so with software, when we hit social media, people started, because I used to use some of these photos in my talks or in workshops, I would show them in the break, and people started sending them to me.

And so I started retweeting them, and it’s become a thing.

I’ve made talks off the back of these things by highlighting here are the errors.

This is interesting.

What does this tell you about this system?

You know, they could have caught this error if they’d used static analysis, or this looks like a gap in their testing, or this is unnerving because one of the most popular ones is this is running Windows, and it’s running a version of Windows XP that has not been supported for over a decade.

And yet it’s now running on something, typically an ATM.

And so therefore, it doesn’t have security, does not have sufficient security.

Should we be worried?

Yes, we should.

So in other words, it reveals something to us.

If you like, it holds up a mirror to what we do.

Yeah, so you think it’s really a security issue.

I once approached on a weekend a banking terminal, and there was a keyboard connected to it because you had to type who you want to send to, and so on.

And yeah, it crashed, and it was on a shell, and it tried to type, and it worked.

And just two weeks ago, I saw an info terminal, and it revealed the IP address and the API endpoint just to get the thing back up and back running.

And yeah, I connected to the shopping mall Wi-Fi and tried the IP address, and so it’s really a problem which people don’t test.

Yes, I think, and that is I think the issue is that one, there is the, as a regular user or member of the public, the most obvious issue is there, I guess there are three issues that some of these failure screens, depending on the nature of the screen and where it is, throw up.

First of all, they reduce our confidence in whoever the company or the place is that is providing it.

Secondly, they can be a, they’re inconvenient.

You know, I don’t want to see an error screen.

I want to see what time my train is going.

You know, I did not stand here to look at this art.

I stood here to get information.

If I’m, if it’s an app that I’m dealing with, I’m probably trying to do something.

I’m trying to buy tickets.

I’m trying to find information, and now I can’t.

So in other words, it’s effectively a denial of service.

It’s not an intentional denial of service, but as a user, I am denied the thing that I was trying to do.

And that’s a software reliability concern.

That’s a software quality concern.

And then we have the security aspect is that wherever we have a failure, sometimes and often, a failure is an attack surface.

You know, bugs are attack surfaces is a very, it’s a very simple way of summarizing it.

We’re not just highlighting that something doesn’t work and that’s inconvenient.

We’re actually highlighting, yeah, there’s almost indistinguishable from a security breach.

And I just want to remind everybody, CrowdStrike was two years ago last month.

And one of the most important things is that that was the largest security incident in history.

And what’s important is the CEO said, this is not a security incident.

It’s just a bug in our software.

And it’s just like, no, you’re the company who is people go to for security and a security, a large scale failure is indistinguishable from an attack.

This was effectively a denial of service.

It was not intentional.

There was no bad actor, but it is a security issue.

And so we can, most failures can be considered security breaches, even though there was not a bad actor involved.

So this is a reframing.

So I find the topic of failures is infinitely interesting in this sense, because it is a reminder of, I think we get wrapped up in our companies, our code, our processes, our tools.

And we forget that somewhere out there, people are actually trying to use this for, they don’t care about all of this.

And so therefore, maybe our priorities are not always where they should be.

The impact of such a failure can be, wow, huge.

I mean, CrowdStrike was interesting, even fun to watch from home.

But I can imagine that there were lots of people trying to catch the flight, trying to get back home, trying to negotiate a contract and missed it, and things like that.

Wasn’t there the saying that somehow Microsoft started this way, somehow that only they showed up to negotiate a contract about MS-DOS?

Oh, yeah, yeah, yeah, yeah.

I’ve forgotten his name.

The guy is CPM.

He was off on a flight.

Because the world could have ended up with a very different operating system.

But yeah, it turns out showing up is, you know, there is that saying, showing up is 80% of success.

Yeah.

So we named this stream, Something with AI and a Mirror.

Your talk at Software Architecture Gathering has another title.

It has AI through the Looking Glass, I think.

Yes.

And to be honest, as a non-native speaker, yes, I know this title, Alice through the Looking Glass or something like this, Alice in Wonderland.

And looking glass, yeah, I thought about what does it really mean?

And so this time, I used the term mirror.

Looking glass seems to be an old word for mirror.

So I will actually just say, by the way, even as a native speaker, looking glass is not, I’m not even sure my grandmother ever used that term.

So in other words, by the time we hit 20th century, people didn’t call them looking glasses.

So it’s a very, if I ask my kids what a looking glass was, they might remember because of Alice in Wonderland.

But I think I learned the term because of that.

But yeah, yeah.

So yes, it is very much about AI and the mirror.

So you already said you still write code by yourself.

You don’t let everything generate.

I mean, we now work with AI, everybody of us, since how long?

Three years, something like this.

We started out with saying, hey, AI only creates slop.

Now we are at another point.

Did your view on AI and coding with AI change through the last three years?

It’s yes and no, which is, you know, it’s kind of yes in small ways and no in others, because I think the other thing we also have to appreciate is wherever you are in the industry, you’re in a bubble.

And most people do not use AI for coding.

I’m going to shock people by saying that.

But we are all in a bubble where we’re looking at social media and all the rest of it.

Most people do not use AI for coding.

We have not yet passed that point.

Or rather exclusively.

So the point there is that there are some people who genuinely pretty much don’t look at the code.

And they’re doing a whole lot of stuff.

And they think everybody’s doing that.

And they live in a bubble where everybody’s using that language.

And they’re talking about it.

And they’re all very excited by that.

That’s not most developers.

Most developers are working in much more hybrid contexts.

And they are still taking initial steps into the world of AI.

Sometimes it’s just simply through a more elaborate auto-completion.

And for me, some of my views on this have changed.

Not so much because some of the LLMs have got better.

But because we’re now seeing some of the consequences.

And some of the things I said three, four years ago are, and this is one of those few times I can say I predicted the future correctly.

I will ignore all the time.

Obviously, I’m going to be highly selective about this day to ignore all the times I fail to predict the future.

But one of the things I said about three years ago, three years ago, I made a couple of tweets on Mastodon.

One of which was, we are going to have to be really serious about testing.

In other words, my specific wording was code generated by LLMs is going to need more testing than code written by developers.

And this is really important.

That has not changed.

What is funny is I also said that in 2016, there was actually a video of me being asked a question.

And this is before LLMs.

This is before the transformer architecture.

Somebody said, what about the future of software development?

And I think they had a much longer horizon in mind, much further in the future.

And likewise, I think we all did.

And funny enough, at the time I said, what we’re going to have to do is work out what it is that we know.

This is knowledge work.

But also, we’re going to have to get better at testing.

Now, this is the thing.

It doesn’t mean, and this is the funny thing I now see with people saying, oh, testing is now important.

It’s just like, no, testing has been important since the first line of software was ever written.

It’s just that people have been really slow.

They’ve found reasons to not do it.

And I don’t mean this in a bad way.

It’s just collectively as an industry, we’ve had a blind spot.

And so 21st, so these days talking about testing is far more acceptable than it was, say, in the 1990s or early 2000s.

So in that sense, my view on a number of things has not changed.

Do we need to have good architecture, good understanding of our systems?

Yes, we do.

Has that changed?

No.

Did I say that this was important when people started talking about AI?

Yes, I did.

I have not changed that.

And in fact, now we have evidence that we’ve got a bigger problem at play.

One of the other observations I made is that LLMs are now, and this was over three years ago, they’re going to be used to generate code.

And without meaning to, developers have moved themselves from a role of being drivers to being passive agents in the process, where they are simply fixing problems and overseeing stuff.

And this is pre-agentic.

And boy, was I right.

I did not mean to be right.

But wow.

And so we’re completely ignoring all the real issues with software development.

And a lot of people have fallen into this mode.

And this is actually not so much the tooling.

This is why I say the mirror is important, because what it does is it shows us who we are and how we work.

And AI is a much better mirror at showing us some of our shortcomings.

And when I say our shortcomings, sometimes it’s an individual thing, but sometimes it’s our businesses.

So I just read the term meat proxy.

Yeah, I saw that term as well.

Yes, I saw that.

I had not come across that term.

Yeah, yeah.

And I see that both with software development, but also other people using, you know, the way most of them remember, always the thing that people always need to remember is most people using AI are not software developers.

And meat proxying is big time.

It’s happening in schools.

It’s happening in regular workplaces.

You know, there’s a lot of meat proxying going on out there.

And in other words, for those of you who’ve not come across the term, meat proxy is simply somebody who basically takes what the LLM says and puts it into the world one way or another.

And it’s just like, yeah, you’re not adding anything to this process.

And that is the failure mode.

That is huge failure mode of this technology.

I now start to understand what you mean by mirrors, that AI puts a mirror on us so that we see our failure, our shortcoming.

I’m not good at telling jokes, but there is this one joke going something like this, that there’s a huge project and by contract, they have to have 80 percent line coverage for the test.

And the senior developers get nervous when it approaches a deadline.

And the junior developers get nervous.

The senior developer says, oh, no problem.

And one day before the deadline, the senior developer just wrote automated tests for all the getters and setters in Java and reaches the 80 percent.

So I guess that’s not the testing we want to have.

And I guess that’s also our future problem.

I mean, those tool providers show us how good the LLM is in creating software.

And after creating software, it writes the test and then it writes the documentation.

And in all my trainings, I say we want to do test-driven development and not development-driven testing.

Do you see this as a problem that people just…

I do.

And I think the problem that we have in this space is that…

So let’s borrow this idea that’s become particularly popular since last year’s DORA report on this, is that we understand AI as a multiplier.

And this is something I found myself saying a couple of years ago because I said, OK, a lot of people are using AI, whether it’s just a simple…

Yeah, this is before we really hit the agentic era.

And honestly, I’m going to say that that doesn’t actually change the narrative that much for this particular aspect.

A lot of people felt they were being better.

They felt they were being more productive.

The statistics actually did not show that.

But what we find with any tool is that it the tool is neither good nor bad.

So, you know, although there are there are a whole lot of questions we have about AI, intellectual property, how the companies who are pushing these things are doing that and all the rest of that’s a different discussion.

If I am given a multiplying tool, there will be some group of people who really understand what they’re doing and they will do incredibly well with it.

There are people now who are using AI who are multiplying to great effect and they are doing incredibly well.

Now, everybody wants to be them.

But a lot of people assume that by using AI, they become them.

And it’s like that’s not how any of this works.

This is why the mirror thing is important.

What you’re doing is you are multiplying a skill and competence that was already reflected in the individuals or the company culture that existed.

They already had that culture and that was their ethos individually and collectively.

And you give them this amazingly powerful set of tools.

And you know what?

Yeah, you get what you expect from such an arrangement.

What most people are blind to is the fact that they work in dysfunctional environments.

Most people are not going to get a benefit.

And in fact, the majority.

So in other words, when you use using AI, developers are either going to find they get what happens is better, the same, the same remixed or worse.

And most people are actually doing worse than they were before they adopted AI tools.

They just don’t know it.

They’re busier than they were before.

They are hitting more metrics.

You just you’ve just talked about statement coverage is like, yeah, we they’re filling the metrics.

We’ve got ticket driven development.

Now, ticket driven development was already a problem before.

I remember visiting a company.

I was just running some.

I was running just some training courses for them.

And what was fascinating is that they I just made some comments about some things.

And they sort of said, oh, I didn’t know you.

We didn’t know you knew so much about the company, Kevin, because you just described all our problems.

And I was talking about the relationship between their product team and the development team and how they were and they were using ticket, what I would call ticket driven development.

And as I said, that’s a terrible way to develop software.

And.

And they tried.

One of the guys tried to get me back in to do some consultancy, but ultimately the company didn’t want to hear this message.

And they no longer.

And what they’ve now done is they’ve got massive adoption, but I don’t have anything to do with them anymore.

And that will only have made the problem worse.

I saw how they were without anything but simple.

But if they have now gone for a full adoption, I imagine that things are not good at that company.

If you’re working there, I think that you’re I think you’re getting through a lot of tickets.

I think you’re very busy.

I think that some people are very happy and a lot of people are going to be very miserable.

And that’s the problem.

That’s the thing that upsets me, is that here we have this tool that can actually help us address vast problems that we have had in software for decades.

And we can actually do them.

We can address them really easily.

We can address legacy code.

You know, we have a tool now that allows us to deal with legacy code in a way that we never have done before.

And is that what people are doing?

No, they’re actually creating more legacy code.

So rather than reducing the amount of legacy software, we’re now using our to multiply the amount and to work around the problems of the previous generation of legacy rather than fix the root cause problem.

So, you know, we have a bit of a problem here.

Most of that’s human nature.

And there are, as I say, I don’t want to sound like I’m being a skeptic.

I’m being a I’m being a human skeptic here.

I think we’re really good.

I actually, you know, I’ve been in this business long enough that most of my optimism has been drained.

It’s been taken away.

So, yeah, when we’re given a good tool, do we do we do it?

Do we use it effectively?

And the answer is actually resoundingly, no, we don’t.

Although it may still transform.

We don’t use it very effectively.

So, I mean, what are you basically saying is first, when I want to use a tool, I have to know which way around I should hold the hammer to use the hammer.

Yeah.

So if I don’t know it, then I will not have success.

I will not have the multiplication of my work.

But yeah, I will multiply the negatives rather than the positives.

Yeah.

Yeah.

When you talk about as a multiplication factor, I experience different things with AI.

I mean, multiplication of my work is a dream.

But I mean, what I experience is that I use AI to help me write more tests, write more documentation, not more features.

I now have the time to do better work.

And that’s not the expectation of the manager.

The manager wants to have less developers.

And what I also experience is that AI enables me.

And that’s why the first question about the language is, I think, so fascinating.

It’s just AI lets me write in every language it wants to.

Not I want to, but AI wants to.

And in fact, you use the hammer point there.

Why do we use a hammer?

Because it allows me to extend further.

You know, I can try to push a nail in or I’ve got this or I’ve suddenly got more momentum.

I’ve got a I’ve got I’ve got this moment on that I can do something with.

And exactly the way that you are describing your usage is the way that I think is one of the most powerful ways of using it.

It’s just like I can do something, but now I can reach further.

I can do more complete work.

My documentation can be better.

My test can be more thorough.

I can get this kind of feedback loop and completeness that I might not have been able to rather than merely go faster.

And that’s the problem is in many organisations.

And we see that you can take AI out of the equation.

And and you still see this desire for speed has been pushed, particularly that I would say it’s increased the last few years.

I think that there’s a that has been so AI came along at the time when everybody was trying to go faster.

The problem is what we find is.

And this actually relates also to the the Alice in Wonderland reference, the looking glass reference with the Red Queen’s race and the Red Queen.

She has to run.

She has.

She has to run just to stand still, basically.

And she actually wants to go somewhere.

She has to run twice as fast.

And that is where we are currently.

In other words, we are much busier collectively.

And again, I need to always kind of qualify this.

I’m not saying that individually everybody’s having the same experience, but in organisation, exactly as you say, people are trying to say we want more features with fewer people.

And it’s just like, tell you what, instead of aiming for more features with fewer people, try doing better stuff with the people that you have.

And in other words, do all the things that you said you couldn’t do before.

Don’t try and increase your current speed because there’s going to be a big surprise for you.

If you try and do everything better, you may discover that you go faster because it’s all better.

You’re not picking up on the one that I’ve really started talking about recently is an idea from John said.

I saw him speak at the first Lean Kanban conference many, many years ago.

And one of the he’s not a software guy.

He’s a kind of systems consultant.

And he’s done stuff for the National Health Service in the UK.

And I was very taken with one particular idea, which I remember talking about way back in the day.

And I’ve kind of forgotten.

I forgot to talk about it until about I don’t know.

You know, something changed in 2020, didn’t it?

And I just remembered these things.

I started talking about it and it just turns out to be the right time to be talking about value demand versus failure demand.

This idea that if we are going to measure something, we should be we should always be careful about what we measure.

But when we are looking at why, where is the demand for our work?

So the economic sense of demand.

Why?

What is it that is causing me to do this work?

OK, so I have.

And the simple way of looking at it is if you have a developer who is sitting there and you say, OK, why are you here at this moment in time?

What are you doing?

And if the developer says, oh, I’m adding a new feature that that customer wanted.

And, you know, it’s and here’s the details of it.

It’s just like, oh, OK, now that sounds like value demand.

We are adding something of value to the system in an ideal universe.

We want all of our work, all of the demand for our work to be value driven.

But clearly there’s something else.

I mean, certainly we know that no system can be 100 percent efficient.

Physics tells us that we’re not going to get a perfect system anyway.

There’s going to be another kind of demand, and that is failure demand.

And failure demand is the work that we do because something’s not right.

Either organizationally, it’s not right or technically it’s not right.

You know, if I ask that development, I’m fixing a bug.

Well, that’s not value demand.

They’re not adding value to the system.

I mean, they’re removing a loss of value.

So you might say there’s a net positive, but that’s not the same as actually adding value.

In other words, their work is fixing a problem that existed or they’re having to do extra work because of a problem that existed.

And what we find is that most work in software development is failure demand.

And this is the thing.

This is the thing that, you know, this is not even an AI conversation.

But when you throw AI into it, you suddenly realize what’s being multiplied.

Most developers are if you are working eight hours a day, honestly, statistically, if you’re doing an hour of value demand, you’re really lucky because most of your work is dealing with problems.

And I don’t mean that in the troubleshooting sense.

If I am trying to understand something, I’m looking at somebody’s got a ten thousand line method in front of me.

And we’ll come back to that ten thousand line method, because that’s quite important.

A ten thousand line method.

And I am wondering how to add a feature.

And that feature logically will.

I need to do something.

There’s 10,000 my method.

All of that extra time that I’m having to deal with is to do with this unmanaged technical debt.

And it builds up a term has recently been used, particularly in connection with AI is cognitive debt.

I’m not entirely sure that it’s good use of the word cognitive debt, but I’m not going to be the one to change the term.

And actually, it’s not a new concept.

Most technical debt is cognitive debt.

Most legacy code is cognitive debt.

It just gives a name to the bit is that I genuinely don’t understand this.

It’s not even that it’s bad, but we can tell 10,000 my method is bad.

It’s just that I don’t understand it.

I lack knowledge.

And that is failure to not having to do rework, re understanding, but also work with stuff.

Most of the work that people do, even if they’re adding a value, if you ask the developer, oh, you’re adding a value.

How long is that going to take?

Well, if this were really good code, it would take me 30 minutes, but it’s not really good code.

I spent all week trying to understand how to do this without breaking everything.

Then that is failure demand.

Most of what developers now do is failure demand.

And that has been the case for many years.

Now we throw in AI.

We have an opportunity.

Here is our opportunity.

We can address the root cause of the failure demand.

OK.

Or we can speed up the rate at which we fix our problems.

And so therefore, what we do is we get better at fixing more problems.

And our value demand also creates more problems.

You know, what we find is that even Anthropic are finding this: they get a slight uptick in the number of bugs.

They’ve got more bugs.

If you use AI, you will get more bugs, which goes back to why it is that testing is far more important.

It’s always been important, but it’s even more important now.

So what happens if I increase the number of bugs that I get in the system?

I have to do work to fix the bugs.

So now most of my work is on that.

But now we also have the additional cognitive debt.

If you are being fully agentic or just vibing and you don’t know what your system is, when there are when you’re trying to add something or re architect, if you don’t know what the architecture is, you’ve got a problem.

And that’s extra work.

If you’ve got problems with it, that’s extra work.

So what we’re doing is we’re becoming progressively productive by having more work to do.

But most of the work is not value based.

It’s actually failure based.

So that for me is that is the blind spot that people have about AI in the sense of how they’re applying it and not seeing they’re optimizing the wrong bit.

They’re getting better at fixing the wrong problem and they feel busy and they feel more progressive.

But actually, if they fixed the root cause problems, I sometimes liken this to, you know, I remember I said everybody wants to go faster if you’re driving.

It’s time for a driving metaphor.

We haven’t used to driving.

OK, you’re driving in your car and somebody says we need to go faster.

You think I will push my foot down on the accelerator.

That will make me go faster.

It turns out one of the simplest ways to go faster in a vehicle is to take your foot off the brake.

And this is what most organizations do not understand.

They have their foot on the brake jammed to the floor.

The thing that is slowing them down.

They are creating low.

They are.

And they’re also trying to put their foot on the accelerator.

So most companies that say we’re doing AI adoption are pushing both feet down rather than saying, hey, we could do something and change our workflow, our work structure and actually address the root cause problems.

And they’re not.

They’re just trying to go faster by pushing their foot on the accelerator.

If most organizations took their foot off the brake, they would find they got an immediate speed up.

And I think that is, you know, my advice to anybody is like AI is a really good tool for a bunch of things.

But are you multiplying the right thing?

Anyway, that’s that’s a whole load of thinking that you’ve just released to me.

Thank you, Ralf.

Wow.

I didn’t manage to trace everything in my mind, everything I wanted to ask.

But in the chat, I see that people find this conversation quite interesting.

I also find it quite interesting because of the speed analogy.

So you said we should go slower in order to be faster by creating better quality in order to be faster.

But the Red Queen’s race says we have to run in order to stand still.

And that reminded me about security.

You have to run in order to be on a fixed position, to be on a certain quality level.

And I think that AI will also be a problem in this case because attackers will be able to use AI to attack our systems.

And we only have some models with the guardrails which say, oh, no, I will not test your software.

This might be an attack.

Wow.

And then there’s also the other speed that I think that the other company is going faster because of AI.

So we have to be faster.

Yeah.

We have to push the gas pedal while standing on the brake.

Yeah.

Wow.

These are huge problems which are.

They are.

And I think you’re right to point out this emphasis.

And I think the way to understand.

And yes, and certainly this whole issue of all these guardrails in place do prevent you from doing sometimes the thing you intentionally mean to do.

They are well intended, but it’s actually, no, I want to be that attacker.

We need to be that attacker to understand our system.

But there is also another point in terms of the efficiency and effectiveness distinction.

And I think I probably I mean, I’ve been around for a long time, but I think I first learned about it through a talk and then a book by Tom DeMarco called Slack.

And and obviously nothing to do with the tool is predates the tool.

But the idea of slack is he was encouraging the idea that you cannot have one.

You cannot.

You should not in your organization have high utilization in terms of the time I’m spending working on something.

You need to have slack because of maneuverability.

In other words, you cannot have your time being 100 percent efficient and organized and ticketed with priority items, because then it means you have less maneuverability.

So although in one sense you are efficient like a machine, then that’s great as long as nothing else happens, as long as nothing else needs your attention.

And security is the thing that, you know, let’s put it this way.

If I am so busy doing all the other stuff and we have a continual we have a security incidents, then I’m too busy doing the other stuff to deal with that.

Or now I have to reprioritize.

We have a competition within the organization as to whose priorities matter most.

And what you really want to have is the ability to say our workflow is stable and sustainable in its normal mode.

And that gives us the slack.

It gives us the opportunity to be able to suddenly address both simple but also deeper security issues.

If we are running flat out, in other words, if I am sprinting, I cannot go any faster.

And then suddenly a security issue comes along.

I’m now really tired.

I’m also dealing with that.

But also I’m going to miss some things.

I don’t have the space to think.

And that’s a really important idea is that we need to keep reminding ourselves we are knowledge workers in software development.

We are knowledge workers.

This is how we work out and arrange the tools.

This is how we ask better questions.

This is how we do these things.

If we are halfway burnt out, then we are not in a position to make the best use of even ourselves, let alone our tooling and our collective intelligence across other individuals.

So security is kind of a reminder.

This accelerated landscape is a reminder of why all this other stuff is important and why you want to take the level down a bit.

We want to be using AI to do the current job better so that then we can have a peak response when it’s needed.

But if we’re always trying to operate at peak, then anybody who’s ever experienced burnout or anybody who’s ever tried to sprint a long distance will know you can’t sustain that.

And therefore you have a dysfunction in the organization.

And that’s going to come back to bite you.

So, again, what does this tell us?

It tells us about us.

AI took the thing that was already there, and it’s allowed us to see how we as tool users, but also in our business environment, how we can accidentally end up taking some of the decisions against ourselves without meaning to.

So the speed analogy, it’s really great.

I mean, you just talked about burnout.

I mean, if I’m standing on the brake and also pushing the gas pedal, the brake will also get hotter and hotter and hotter.

And Gregor Hopper, I think he was it, who said, in order to go fast, you need a brake.

No, that was me.

Gregor has a different one.

No, that’s me.

He has always the car analogies.

Yeah, he does.

So I think this is really great because if enterprises would recognize that, yes, a break is needed, but you don’t have to push it all the time.

You have to let people go, use the systems, experience what is possible.

And if something goes wrong, we have to break.

Yeah, and this is really cars.

Yeah.

Cars have brakes so you can go faster is the simple way I put it.

But we can take a step back from that and actually say you have brakes so you have control.

And that’s a really important idea that that control is exactly what you need.

And this is the idea is that a lot of organizations, it feels like they’re trying to just go faster.

If it’s as if they are trying to run a hundred.

Yeah.

And the whole point is 100 meter race is a race in a straight line.

And the goal of that race.

I mean, I’m not saying it’s trivial.

I can’t run 100 meters very fast at all.

But the goal of that race, if you look at any hundred meter race is go fast.

But if you look at a long distance race, software development is long distance.

And it’s a shame we use the sprint analogy.

I know historically why we use the sprint terminology.

But people picked up on the sprint terminology and heard something different.

The idea with a sprint is that you have a period of sustained, consistent, high unsustainable.

You know, for a short period of time, you sustain something that is unsustainable.

Okay, you can, you know, you can run 100 meters, you’re not going to run 1500 meters, although honestly, if I ran 1500 meters at the speed, if I could run 100 meters at the speed that Olympic runners run 1500 meters, I think I’d be very happy.

But the point there is you cannot sustain, the whole point of the sprint metaphor is that when you’ve done with your sprint, you take a break.

Because it’s not sustainable.

And that’s, and that seems to be the way that a lot of companies and their cultures and management and product owners and whoever I’m not, I don’t want to point the finger at any one individual, but culturally, this seems to be a problem is that they are trying to run marathons, using sprint mindset, they’re trying to run fast.

And it’s just like, that’s not how you finish.

That’s not how you run the race.

That’s not how you do it effectively.

I used to do a bit of distance running.

And one of the things that if you watch anybody doing a 10,000 meter race, you will find that, particularly the Olympic level, the 10,000 meter runners, the person who wins the race is often not the person who’s at the front at the beginning.

And that is, you know, I remember my kids, we watched the 2012 Olympics.

And that was in London.

And my kids was like, Oh, no, Mo Farah, he’s not going to win.

He’s at the back.

And I said, Just wait, just wait, you know, he’s at the back for the moment.

But in the last 1000 2000 meters, you’ll see he moves, because he’s understood the pacing he’s under.

And this is the whole thing we need in software, except also in software, just to make it hard.

It’s dark, and there isn’t a track.

Apart from that, the race analogy is perfect.

The point there is that we need to understand product development is something that happens with lots of surprises.

You need to be you need genuine agility to be able to respond situation, which means you cannot always be working flat out. optimizing your current approach to be hyper efficient is not helpful, because that’s not the product landscape products change in a way that requires maneuverability.

You need a steering wheel, you need to understand, sometimes you need to slow down and say, Wait a minute, let’s not do this.

There is a skill in not doing something and then changing something.

And sometimes and this is the problem is one of the things I think we are finding is that people are finding that they have people who have historically perceived software development as a typing activity.

Now think that we’ve solved the typing problem.

And it’s just like, no, it was never a typing problem.

Because otherwise, we’d have solved that problem years ago, we’d just send everybody a touch typing courses.

It’s just like, that was never the problem.

And that that whole issue is that they are optimizing the wrong bit.

And so now we see this in organizations, that they they now create bottlenecks in different places in the organization.

In other words, if I am producing lots of code, how do I know it’s any good?

And that’s a very broad question.

But then who are the other people that need to depend on this?

And what’s the relationship with the customers, the product owners, the QA department, all of this kind of stuff.

And we now slam into other things.

And we may be producing the code that’s produced now is not the same kind of slop that’s been produced two years ago.

But it can still end up being slop in the sense of nobody’s reviewed it, nobody’s really tested it.

Nobody’s really explored it.

And now we’re going to pass that on to the next person to deal with.

And that’s unfortunately a pipeline model that some organizations seem to be walking into without realizing it.

So you just answered another question of me.

Because I think in the beginning, we all said, oh, that’s AI slop.

And now I think it changed.

The quality of the reviews AI can do is, yeah, I would say better than the quality of the reviews I do manually.

So I won’t judge anybody else.

But the code is also better than what I produced the last 30 years, and so on and so on.

But isn’t it also about expectation management, going fast?

So you just told about a racetrack and you told your kids, hey, wait a moment, it will be faster.

And while watching television, I think it was not such a big timeframe.

So the kids said, yes, let’s wait and see whether that is right.

But with software development, everybody says, wow, we invested so much money and we can’t wait.

It has to work out.

And I think that’s a huge problem.

And from the start, when you get the first proof of concept in just some hours, and the customer says, okay, it’s working software.

Why do you need some more weeks?

And then you have reasons that you have to implement some more things, some more layers.

Security, logging, so that it also can be operated and maintained.

And then you hit a road block.

You can’t keep up the speed because you hit a roadblock where AI doesn’t succeed anymore, where you can’t use the multiplier AI anymore, you drop down to normal speed.

And I really hear that this is happening.

Normal speed or slower.

And I think that’s the thing is, and as you said, it’s about expectation management.

And the problem is that, so this goes back to this issue of understanding the different expectations people have from AI.

So one of the things that I find, particularly when I’m exploring ideas, is that AI is particularly good at helping me explore ideas.

Let’s go back to this idea of knowledge work.

I can now explore alternative solutions far more rapidly than I could before.

That’s fantastic.

In other words, I can get a better understanding of things by exploring options.

In other words, set-based thinking made real.

But that’s not what I see most people doing.

They are meat proxies.

In other words, they are now going for the first solution that’s generated and stick rather than say, well, that was really convenient having that generated so quickly.

Let’s look at another option.

Let’s bounce ideas around.

What if we did this?

What are three ways of doing this design?

What are three ways?

And exploring the options.

And in other words, the relationship there is that that enhances us.

In other words, what we’re doing is we are saying, what are the options?

There’s this quote that I use from Emile-Auguste Chartier, that in English translates to, there’s nothing more dangerous than an idea when you have only one idea.

We often get locked into something.

I think it’s a good quote for life, by the way.

But we often anchor on one idea, one way of doing something, or the first design that comes to mind.

Here we have this impressive tool that allows us to explore multiple ideas with ease.

Do people use it like that?

Not that many do.

I mean, yeah, I’m sure a number of people watching now are doing it.

But the thing is, as a percentage of the industry, no, most people are just doubling down on doing one thing, trying to do it faster rather than saying, oh, this is interesting.

You know, our job is to think it is to come up with a reasoned approach.

No, this is the better approach.

And you spend less time than historically you would have done, but you’ve now explored more options.

The idea of being able to explore more options is incredibly powerful.

It’s one of the, you know, I have a kind of a mental hit list of things that AI allows us to do that we should probably spend more time focusing on.

Generating options and exploring them at a cost that is far reduced from how we used to do this, that’s fantastic.

Addressing our legacy code, that’s fantastic.

We should do that.

Let’s reduce the failure demand so that everything that we do, or more of what we can do, can be valued.

In other words, it changes the balance of work.

But what I see is that that’s not in what most people are doing.

I don’t think most people do know what they’re doing, in this sense, from the big picture point of view.

And as you said, the expectation often comes down to, we are adopting AI, we put so much money into it, I think everybody was very surprised by how many tokens one could burn in a short period of time.

And we put all this money in, it better work.

But I think the problem is that in many cases, and this is not new with AI, but again, AI really throws it back in our face, is that people didn’t know what they wanted.

Why do you want it?

Why are you doing a big AI adoption at your company?

Because everyone else is.

No, that’s not a reason.

People who’ve got kids will know that they eventually their kid will come back from school one day and say, I want this.

And you go, why?

And they say, well, everybody else has got one.

Yeah, you know, it’s just like, wait a minute, that’s not really a reason to have it.

And that’s the problem.

So that’s not a good expectation.

You can’t measure that.

So the real question is, with any tooling, is what problem are you trying to, what are the problems you have?

And that’s the first question, forget AI, what is it that is current?

Where is, you know, what are the breaks in your organization?

What are the things that are slowing down?

Okay.

And what are the things that we could be doing?

And then, you know, that we’re not, and what are the things that this tool will allow us to do that we’re not?

And yeah, and just simply just writing that out on a whiteboard, and doing this collectively is a really, it’s a helpful exercise, because it actually refocuses.

Oh, you know, our biggest problem is this, is AI going to help with it?

It might do or yes, this is perfect.

It’s a good match.

I don’t know what the answer is in your organization.

But if you don’t ask the question, there’s no way that answer is going to magically match up.

And I think that’s the problem is people are doing it with this big, fluffy idea of AI, you need to be need to remember, it’s a tool, it’s a very powerful tool, it’s a tool with a great deal of breadth, but it also has a great deal of latitude, very huge amount of possibility for not actually being as effective as you think it is.

It’s not, you know, and that’s, I think, the problem we get in conversations, you know, you were talking about the, you know, the detail, what hitting 80% statement coverage is through testing getters and setters.

And that’s the conversation many people have, they have a we need better testing.

And one person can be writing full kind of TDD style, descriptive, BDD style tests, and another person can just be testing getters and setters.

And they don’t know they’re having a different conversation.

They’re using the same words and the same metrics, but they don’t know they’re talking about different things.

But the competence level between them is hugely different.

And I see that with people talking about AI is that you’ve got somebody who’s truly mastered and understands the relationship between the organization, the developers, and their tooling, and how AI can shape that.

And then you’ve got somebody else who’s really just multiplying some of the bad stuff in an organization that doesn’t have a sense of direction.

And they’re both having this what they think they’re talking the same things, because they’re talking about the same tools, and they’re not having a different conversation.

I really liked the idea about the options.

When we think about the definition of architecture, we most say it’s the sum of all decisions.

But in order to make a decision, we need options.

And so we should try to keep those options until we have to make a decision.

And someone once said that a decision without options is a constraint.

You don’t make a decision.

You just take this constraint.

And I think that’s quite interesting.

In the chat, we have one comment.

I would like to reference it.

How about following standards?

I think it’s a software engineering knowledge and other books of knowledge.

And I think we started out with the testing, and I think it already answers it.

The knowledge we already have, that we collected the last decades, still holds true with AI, doesn’t it?

Yes, I think.

And that for me, there’s kind of an interesting one that I’ve noticed, that a number of…

I kind of joked about it on social media earlier this year.

I said, one of these days, I’m noticing a lot of people rediscovering or reinventing ideas that people have been saying are quite important for a long time.

I think it was specifically in response to somebody saying, hey, here’s a really good idea.

When you’re using LLMs in your development flow, and all these things are happening, how do you know what’s happening when it’s addressing the question of cognitive depth?

And basically, what they’ve done is reinvent the ADR.

And it’s just like, thank you for joining the party 15 years late.

In other words, I’m seeing a lot of people reinventing stuff and people discovering that things like coupling and cohesion, they have consequences.

It turns out that…

Let’s go back to that 10,000 line method that I promised we’d go back to.

There are two things about that 10,000 line method.

First of all, humans find it really difficult to understand 10,000 lines of code in a single method.

You know what?

LLMs do as well.

They’re not quite so good over long distances.

LLMs like things that are small chunks, loosely coupled, well-named, clearly structured, have obvious control flow and data flow.

Guess what?

They’re not identical to us, but the number of the things that work well for us also work well for attention.

Remember that the whole transformer architecture, the architecture we now work with in LLMs, is attention-based.

It’s about the understanding that we have a limited attention construct, even though that is a metaphor for them and a reality for us, that if we work to those constraints, then we tend to work better.

Guess what?

This is not a surprise.

Therefore, having separations in our architecture, points of interchange, decoupling, good interfaces, clear specifications of what happens on this side, so I don’t have to care about the implementation, all of this stuff is what many people have been saying for a very long time.

In other words, it reinforces these ideas.

As you say, architecture is about understanding the options.

Also, is this an appropriate option at this point because the trade-offs may change.

In two years’ time, I may revisit that decision because the landscape of technology or the market has changed, and I want to know what the options are, and I want to be able to do it objectively.

All of these are exactly as true as they were before, and in one sense, we’re in a better position to take advantage of them, but I think that the problem is that many people aren’t taking advantage of it because they’re thinking, like, hey, code generation, that’s all I need to worry about.

It’s like, no, you kind of need to worry about, you know, it’s not a fire hose of code.

I still want a system that does the right thing in a way that does not cause security problems, high maintenance costs, you know, all of these issues in future.

In other words, I’m constantly exploring that landscape, and when we look at it from that point of view, we take on a very different role or we look at AI through very different lenses.

If we just look at it as can I produce more lines of code, then, of course, you can, you know, but that wasn’t the problem.

It’s can we understand the landscape and the tradeoffs and balance it and to do so with effectiveness and awareness and reach further than we could before, and that, I think, is that’s the opportunity, but I don’t think it’s an inevitability.

I think that’s the problem that we have is that I think we look at all the best demos and the companies that are really doing this well and the developers and the advocates of what I would call the effective use, and we say, yeah, I want to be like that, and yet we’re in an environment that almost pushes us away.

In fact, I can see that in the comments, is that the environment pushes us in the opposite direction.

It discourages us.

It kind of nudges us away from this idea exactly where you began with this of saying you are using this to create better tests, better documentation.

It’s multiplying that desire for effectiveness and quality, and I think that’s our opportunity that if we don’t take it now, then, you know, I’m not going to say we’ll never do it, but having seen, let’s go back to that 10,000 line method.

That 10,000 line method, let me tell you, imagine that it’s in Java, and these methods do exist.

Here’s the point.

Java has had refactoring tools for decades.

Java is the language in which refactoring grew up, okay?

It’s the language where it became normal, and so for over two decades, we have had all the tools that we need to address most of the things that people complain about in legacy code.

We have been able to…

It’s a signal about the language.

Yeah, but it’s a case of here is an environment in which refactoring is a normal thing, and the tool support has been around for decades, so what is interesting is that, you know, and I sometimes joke about this, you know, it’s just like, oh, it’s really great working in languages through refactoring tools.

You never have legacy code, and people kind of laugh nervously, and I say, well, that tells us that it wasn’t a tool problem.

It tells us it’s an us problem.

But regarding the refactoring tools, and I think we could go on with this talk on and on, so it’s quite really interesting, but we have to come to an end.

So with those refactoring tools, we used the refactoring tools.

They helped us to extract methods and get getting classes under control, and so on and so on, and it seems to me that we now forget about those deterministic tools when we work with AI.

AI doesn’t have those tools.

AI knows how to refactor, but in a slightly non-deterministic way without those tools, and this brings me to the closing question.

The next generation will grow up with AI, with code generators.

They will not learn the basics as we did by manually typing code, doing our mistakes, writing big ball of mud systems.

They don’t have this experience.

So I think this is currently the hardest question.

Question, what is your advice for this next generation which will grow up with AI?

What is a skill they need?

Okay, so that’s a, oh, we could probably spend an hour on that question.

We obviously are not, but my advice is to make sure that they understand that they need to be involved in the coding.

They don’t have to be involved in the coding the way that people were in the past, but it will be healthy.

If they don’t feel comfortable writing a simple function, then that tells you something.

It’s a case of like, oh, you should do, because you still have to know how to read this stuff, because the code is a precise and deterministic specification of what you want.

The code is not an implementation.

It’s a specification.

That’s what all programming languages are.

They are specification languages, and that’s a really important understanding.

So the idea is that you still need to be able to read this.

Why?

Because you need to understand what you have.

You need to understand how to change it.

You need to understand what to do when things are wrong.

Now, that doesn’t mean you can’t use an LLM in that process, but the idea is you still need to have that kind of level of being able to do it.

Now, perhaps you, but let’s, let’s relate this to something else.

Latin.

There’s not a lot of, you know, if I, if you, if you, if you learn a language, so, yeah, my German’s not great.

I always talk about my German as being speisekartendeutsch, you know, so I can, you know, I’ve got a certain level, but I can order from a menu.

I can ask for where the toilet is.

I can understand when my flight has been delayed.

You know, I’ve got the basic bits and pieces, but let’s put it, you know, I can introduce myself, ask for food, ask where the toilet is, you know, ask for basic things.

If you learn Latin, learning Latin is actually really different.

It’s not like learning a modern language because you don’t need to introduce yourself.

You don’t need to ask where the toilet is.

You don’t need to order a meal.

You are typically reading things that already exist, written texts, and the point there is that even when you learn Latin, you learn the intricacies of the language, okay?

The same goes for ancient Greek, and you’re reading classical texts, and I guess also, to be honest, things like Anglo-Saxon, Old English, and stuff like that.

These are not languages that are written anymore, but to understand what is there, that’s the key thing I would tell people is don’t vibe your way through.

If you are a, if you are professionally a software, if you’re not professionally a software developer, different recommendations, but if you are professionally a software developer and you do not know what is being generated on your behalf, and you don’t understand the relationships in the code, and you don’t understand enough of the language to make an assessment of it, in other words, you can’t read the Latin, that is a problem.

You are denying yourself, you’re denying yourself a level of knowledge that would actually allow you to be more effective.

You are denying yourself a level of knowledge that would allow you to increase value and reduce failure demand.

You may not have to be fluent in spoken Latin, but you are, as it were, holding yourself back from getting the most out of the tooling and looking at it from that point of view.

So yeah, I still encourage, I would encourage people to do that, and there’s a lot of discussion about, oh, but surely, you know, we don’t, we work at different levels of abstraction.

I have a whole talk coming on that issue, but yeah, that’s a different discussion.

I now wonder how many chances are there to experience spoken Latin nowadays?

These days there are more, that’s true.

I mean, I’m not a Latin speaker, I had to, they made me study in school, but there are opportunities, and spoken Latin is a thing now in not just church Latin, not just the Vatican, but typically, I mean, I remember learning Latin, that was not a case, you were not expected to generate much Latin.

You did a bit, but not, you know, it was competition.

Okay, Kevin, we are already over time.

It was such a great talk with you.

I learned so many things.

I bended my mind a little bit, and I’m really looking forward to meeting you in Berlin at the Software Architecture Gathering.

This will also be quite interesting.

You have a workshop, you have a talk.

So, wow, thank you for being here.

Thank you for inviting me.

And I hope we can have a coffee in Berlin.

Yeah.

Bye.

Hi, I am Alain Roischenbach.

Do you organize any user groups, conferences, or other tech events?

Then feel free to add them to treff.tech, an uncommercial platform for tech events in the German-speaking community.

It’s free, without any advertising or tracking.

Just visit treff.tech or scan the QR code.

You will also find that link in the video description.

And by the way, you can find all Software Architecture stream events also on treff.tech.

And if you have any questions, feel free to reach out to me.