This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub
Yeah, so welcome everybody to another episode of Software-Architektur im Stream, this time with Sander.
So great to have you on the show.
Before we actually get started, there is one announcement that I want to make.
So my colleague, Lukas, has started sort of a sister stream, which is called Maschinenraum.
So that is going to be more machine room in English.
So this is going to be more about concrete technical things while we will continue to do the software architecture stuff in this stream.
So Sender, do you want to say a few words about yourself and thanks for joining by the way?
Yeah, thank you for having me again.
Yeah, what can I say?
Well, I am a software developer by nature and also a software architect and I’ve been writing code since 1987.
No, that’s basically when I started making money with it.
So I’ve been writing code for a very, very long time and things have changed over the last year, let’s say a year, a lot.
But that means we still write code, but in a different way.
I used to work for large consultancies for a very long time.
And I went freelance like 15 years ago and since then I’ve mostly been doing CTO roles of smaller companies, because I like to work for smaller companies, because that gives me the opportunity to both deal with the strategy of the company and still write code with my team every day, which I do.
And next to that, I do a lot of talks at conferences, I’ve written a bunch of books.
I have three kids.
I live in Amsterdam.
I have a really nice girlfriend.
And the funny thing is, as a developer, I live in the Java Street in Amsterdam, which is of course named after the Indonesian island, because all the streets in my neighborhood are named after Indonesian islands.
But it’s just a coincidence, right?
And yeah, that’s me.
And I work for this company called iBOOD.com, which is an e-commerce company active in six countries, Germany for one.
And it is a very interesting concept because it has daily different deals, which makes us different from a technology perspective than most other e-commerce companies where existing tools, for instance, can deal with the stuff you have online if it stays online longer, because then they can see what recommends and what people visit and et cetera, et cetera.
However, we take most of our deals offline after a day, because they’re sold out or not.
But that means it’s really hard to connect to default tooling, which means you have to do a lot of stuff ourselves, which is really nice.
That makes it a very interesting challenge to work here, actually.
Yeah, great.
And you will also talk at the Software Architecture Gathering.
So this is one of the episodes in preparation of the gathering that will be in Berlin on the 16th to the 19th of November.
And we have a special discount code.
So it’s SATV under bar 15 for 15% off to any ticket.
And I will also be there and we will have live stream from there.
So that’s how we got started about this.
Exactly.
Okay.
At that conference, you will talk about surviving the AI native era.
And there are quite a few things that, as you said, that you changed during your way to AI-based development, I guess.
And you just said before the stream started that this is a journey and you’re doing things differently all the time.
And I took some notes.
So in your abstract, you said that you’re now doing trunk-based development instead of pull requests.
Why and how is it different and how does it relate to the usage of AI?
Oh, yeah.
Good point.
Well, we’ve been doing trunk-based development for a very long time already, probably a decade or more with different teams at different companies.
And it’s basically, you could say it’s part of that journey.
And that journey for me started a long time ago when we were still doing Waterfall.
And the ways of working with teams has changed throughout that 40 years in this industry.
And I think that’s, in its core, what Agile is about.
There’s a lot of posts nowadays and voices that say, yeah, but Agile is death.
And I don’t agree with that.
I think Agile is very much alive because Agile, to me, means what it is in the main statement that says we are uncovering better ways of developing software.
And that hasn’t changed, right?
And anything that fits to that makes you more Agile.
So what is that is that the frameworks that people invented to work in a certain way, which seem to be immutable, those are dead, basically.
Because what I see is that the more we move into the AI era, the more the ways of working diverge instead of convert.
So it’s like, if I look at my team nowadays, and we talk about this a lot in my team, is that we see that where we put our basis is very strict, right?
We have everything automated from, we know what our architecture looks like.
We put that in skills too, by the way, but we know our pipelines.
We have a lot of them because we do, we have a microservices architecture.
So we have about 160, 170 different pipelines, but they’re all the same, basically.
They’re all templated, of course.
So that workflow is always the same.
The fact that we unit test everything, the fact that we have tests on every stage in our process, including in production, to see if everything still runs in production all the time.
That is a very firm basis for developing software.
So before AI hit us, so let’s say two, three years ago, we had everything very much standardized.
That means I could write a bit of code if I wrote my unit test to it, and I checked it in the pipeline brand, and it would be in production in 12 to 15 minutes later, literally.
We were doing full continuous deployment for quite some time already, and we had set up, so my team and I, we’ve been working at iBOOD for six years almost now, and we have set it up in ways that we so much automated that we went from, let’s say, a few commits per day and a few pushes per day to about 100 pushes per day to production.
And if the pipeline was green, it went to production all the time.
Now, that has an effect on how you develop software.
If you can have your changes in production in 15 minutes, literally in 15 minutes, and that’s only because of the slowness of the pipeline, not because of the speed at which we develop, that allows you to go faster and faster, and the faster you go, the shorter the feedback loops are, and the shorter the feedback loops are, from us to business and back, right?
The shorter that these feedback loops are, the more trust you gain with the people in the business, right?
If they can say, okay, actually, we want this and this and this, and then we can say, okay, we’ll have it ready for you this afternoon.
And that means that for them, their thought process shifts from, I need to tell them everything now, because otherwise, they will never get it.
On having sprints, which we also don’t have, people are a bit like, yeah, but if I don’t tell them now, I’m afraid that I’ll never get what I want.
But if you go to a cycle where he says, okay, can we have this and this?
And we say, yeah, okay, we’ll do this, and we’ll have it in the afternoon for you.
That means they can sort of relax, slow down, and say, okay, I only want this now, and then we’ll talk about the rest later.
And that changed perspective.
Now, trunk-based development is part of that, because the shorter your cycles, the smaller the features are that you want to implement at once.
Once you learn how to break them down into really tiny pieces, that means you can pull the code from the repo, make the change and push it back again without anybody else touching it in the meantime.
Now, that gives you a bunch of constraints and also a bunch of consequences that you would like to have is that on trunk-based development, you want to check in as fast as possible, because you actually don’t want to have merge conflicts.
So to avoid more merge conflicts, you make stuff smaller and smaller, which very much contributes to having shorter cycles.
So going to trunk-based development actually means that you’re going to be able to shorten your cycles even more, meaning more feedback, faster feedback, meaning you can go faster and faster.
And so going to trunk-based development contributed largely to being more agile.
So it removed necessity for having sprints a long time ago.
So we don’t have product owners because, well, the people from the business are their own product owner for the stuff that they contribute.
And we are sort of becoming, I call it product engineers.
So we engineer the actual product of the company together with the business.
So there’s very little, there’s no man in the middle anymore.
And that speeds up again.
So if you’re an e-commerce company like we are, you want to be as fast as possible.
There’s other companies that are, or organizations that sit on the opposite side, right?
So if you talk about banks and government agencies, ministries, they don’t have that need for competition, meaning they don’t have to do this, but being an e-commerce company, you want to be able to change as fast as possible, right?
If one of the competitors introduces whatever, an AI chatbot for their customers, which a bunch of the larger ones now seem to have in place, then immediately the necessity for us to do that too, basically being FOMO, of course, but, and that means we can work on it really fast.
And this actually hit us yesterday, and I think we’ll have a first version of it ready on Tuesday.
So it’s not that we didn’t know that it was coming, but we postponed it as long as possible.
Make the decision as late as possible and then build it.
So that all sort of, it nicely falls together into a very different way of working.
And then moving into the AI era, well, that changes a lot again, and that changes daily, basically.
Yeah.
So, I mean, I really like how you made the point that Agile is not like the one prescribed way like Scrum, but it’s about constant improvement.
And I also think it’s a very important point that you made, that trunk-based development even means more speed and is sort of the ultimate version of Agile in a way.
But, I mean, what, basically the subject of what we were going to discuss is AI.
And the point, in a way, that you made is there is so much speed up that you can gain by doing things like trunk-based development, proper AirTrial development, and so on.
So do we actually need AI?
Because, I mean, if we just do trunk-based development and proper AirTrial processes, we are already quite quick.
So is AI really the thing that we need to become even quicker?
That’s a good question.
Quicker is one of the things that AI could bring.
I think what it even more brings is the possibility of doing things that we couldn’t do before, or didn’t have the time to do before.
Okay.
Yeah, and it also brings quicker, actually.
I was actually thinking about if we are actually increasing in speed, and our management team, of course, would like to see that and would like to see that in a chart.
So we did a recent investigation on the number of topics that we close on our boards, and it is actually increasing.
And we try to keep the size of those tickets, or tickets that we close, and we try to keep the size of those tickets, or, yeah, tickets is a JIRA-like word, but the size of those topics, issues, similar size, because that makes it easy to measure.
So we don’t estimate, we just count, because estimation, yeah, it’s very a relative understanding of what you’re doing.
And software development has always been hard to estimate.
But I think what it, so the journey towards, or moving to, let’s say, agentic coding, or whatever the phrases we use these days, has been a very interesting journey.
And we’ve been there from the start of when it started to get popular to use for coding.
So that’s probably a year and a half, two years.
And we’ve seen, so I’ve been doing talks about how we work with AI for quite some time, and that talk continuously changes.
It’s like the insights that I have today, or actually, I was doing a talk at a conference in Croatia earlier this week, and I just redid my complete talk.
So the title was still the same, but the contents of the talk was really different from the previous edition that I did right before the summer.
And that made me realize that there is no way that I can now create a talk for a conference and use the same talk for half a year or a year, because it will be outdated.
And if I look at previous versions of these talks from like a year ago, we were still trying to figure out, what’s an MCP?
Should I write code with AI?
Can it write my tests?
And all these very basic questions.
And that has changed tremendously over the last, let’s say, six months, or basically since Claude came out.
That was the big game changer for writing code, I think.
And now everything is, but not so much about, oh, there’s a new model.
Let’s move to the new model.
We do that all the time.
We’re not even, in my team, all on the same model anymore.
So we use different LLMs with different tools and different harnesses.
And I think what opened my eyes is when I started investigating things and doing things that I purposely did not do before.
I’ll give you one real example.
So we have a UI library underneath our own UI library, which is open source.
It’s Chinese.
It’s called Ant Design.
It’s the Alibaba UI framework, which is a very good framework.
We started using that six years ago because, well, you don’t want to write your own form components, your table components, the more complex things.
And for quite a while, I wanted to get rid of ND because it’s quite big, which means it slows down the loading of the website, et cetera, et cetera.
And over the years, every year, I came to the point that I was like, I really want to write our own table component instead of using ND’s table component.
So it would become much lighter.
And continuously, my team says, don’t do it because it’ll eat a lot of your time and it’s not worth it.
And then when Claude came out, I was like, I should probably investigate if I can now build our own table component.
So I did.
And it took me about three, three and a half days.
And then I had a fully functional table component with everything in it that was also in the component we borrowed from ND, except that it did not have a library underneath.
And it was only 250 lines of code.
And the fact that I could do that in three days, and we’re now replacing all the other table components that we have with ours, it’s actually faster even, that was a thing that I couldn’t do before.
And we’ve been on that path in a much larger extent.
People started building their own tools.
There was a guy on my team said, you know what, I’m going to build a notification thingy on my Mac that notifies me when one of my pipelines fails.
And at that point in time, and I’m not talking like half a year ago, maybe, that was like, oh, cool.
Should we do that?
Yeah.
Okay.
And then we went on and on.
And now if I look at what we are doing today, I’m in the office now and one of my team members is sitting next to me.
This week, literally this week, he built his own IDE.
He stepped away from WebStorm, away from VS Code, away from whatever we’re using.
And he said, I have a very specific workflow in the way I like to work, still in the guardrails of how we do architecture, how we do pipelines, how we test, et cetera, et cetera.
But I’m doing more complex things.
So I want to be able to write a plan, look into it, and being able to make changes in multi-repos, look at it, comment on the changes, go back, et cetera.
So he built, literally this week, his own IDE.
And that is not something I would ever have imagined to be able to do.
And the funny thing is, I was looking at it, I’m like, yeah, I actually also have my own way of how I work and how I work with the AI.
I’m also going to do this.
And he says, well, you can clone mine.
And I’m like, yeah, but my ways are slightly different than yours.
I’ll build my own IDE, my own personal IDE.
And we were at that point in time.
So also our collaboration with the business changed a lot because they’re also vibe coding now.
And that means that people from our buyer community, they are actually coming to us with, hey, can we have this?
And then they come up with a almost fully working prototype, which, of course, doesn’t have all the needs from an enterprise perspective, but it does work.
And it does show very good at what they need.
So they thought about it.
And instead of coming to us with a bunch of requirements, they come up with a working prototype.
So it changes so much in how we work.
It’s, yeah.
So concerning that point, I mean, what you seem to be saying is that we are now doing stuff that was not possible before because it was just too much, far too much effort.
I mean, you gave the example of the IDE, you gave the example of the table component.
And I mean, there is the fear in our industry, I guess, that all the developers will be out of a job in the not too distant future because of AI.
Now, what you seem to be saying is the additional productivity is just invested in doing more stuff, stuff that was impossible before.
So what do you think?
Will we have more developers that are unemployed?
Will the total number of developers decrease or will we have something like you seem to be experiencing in your company where you’re now doing stuff that couldn’t be done before and the number of developers, I guess, probably you’re still even hiring.
So the number of developers stays constant or even increases.
What do you think will happen in the industry and what happens in your company?
Yeah, this is the most difficult question to answer, of course.
And it’s the question everybody asks themselves, right?
And it’s rightfully so.
To be honest, I don’t know, actually, and it’s very hard to predict where we’re going.
So on one hand, I see that a lot of the more low-level works, let’s say decoding work, can be handled quite well by the AI.
And this is not a marketing talk.
This is what I see in my code base, right?
It’s literally the code I’m writing today looks quite nice and it fits into how we do this.
So the firmer your basis is, the more you can use AI, right?
If you are already in quite a mess without AI, then you will stay in that mess because AI is not going to make it better than it was, right?
So if you have 20 million lines of code, legacy code based in COBOL or Java or whatever other language, it doesn’t matter, that’s still going to be tough.
So that’s one aspect of it.
The other aspect of it is, of course, what I said is that we can do things that we never held possible.
So there’s a lot of companies supplying services and platforms and tools that are going to be, well, they’re going to be in a pickle, basically.
So if you are now a tool supplier, let’s say you’re JetBrains now, right?
I would seriously. would have to reconsider what we’re doing as a company if I were a company like JetBrains, right?
I love JetBrains, but, or if you’re a SaaS provider, for instance, like we use Voucherify for coupons, basically, right?
So they provide a service, which online we pay for that.
And we’re actually looking into that, like this is not super complex.
This is a domain we could tackle as well.
So that’s another aspect, is that more and more developers at those kinds of companies will be, well, those kinds of companies are going to slowly, well, fade out, basically, a lot of them.
Like if you’re Atlassian, for instance, that’s, Atlassian is a good example, right?
People in the business, people in the business here at iBOOD built their own dashboards, right?
They move things on a Kanban board.
They built their own Kanban board software on whatever they do.
And they now have all have their own dashboards, which is not sure if that’s a good idea, but tools like Jira become obsolete because everybody’s doing that by themselves.
And that doesn’t mean it has all the features.
So if you need the 10,000 features it has, you’re fine.
But if you only use the fact that you have items that move on a board and that you can assign to somebody or a team or whatever and get notified, people do that by themselves.
So that’s another shift I see starting is that people will move away from standard tooling, standard apps, standard websites, even.
And the whole landscape of where we are with tech is rapidly changing.
And for a developer perspective, that’s on the one hand, there’s gonna be, well, sort of jobs lost on that side.
But on the other hand, the vast amount of new possibilities that we have are gonna trigger much more, let’s say wishes from the business.
And I see that and too, right?
People get very bright new ideas.
Like we’re gonna build a loyalty platform probably really soon.
And that’s the thing that I wouldn’t have thought about six months ago, but now the business says, hey, we can do this here.
Look, here’s the prototype.
So there’s a multitude of new possibilities coming up, which means there still need to be people in tech, making that safe, secure, scalable, et cetera, et cetera.
So there’s still work.
And on the other hand, the time it costs to do coding, testing is diminishing.
So you also see, so that is the, so it’s pulling in both directions.
So where it will end up, I have no idea at this point in time.
Yeah.
So thanks for answering the question.
I would like to boil it down to a yes, no question.
And I’m not sure whether you’re allowed to answer it.
So obviously your company is very invested in AI.
I mean, that’s basically what we’re talking about.
So do you still hire new developers?
Are you still increasing headcounts in development?
No.
In engineering?
No.
Dan, I also have to tell you the story about that is that I came to iBOOD six years ago and we were, it was a very interesting situation because they had a landscape full of tools and packages and solutions.
And that was all syncing data and so forth.
As a result, they could not, or we could not, for instance, deploy new versions of the app or the website.
So they got totally stuck.
So at that point in time, I was working for a company that built the very first smart thermostat in the world, I think.
And that company was taken over by a large energy vendor.
So my team and I decided to sort of move.
So I took my team, we went to iBOOD and we merged with the existing tech team into a team of 12 people at that point in time.
And since then we have been automating as much as possible in our workflows.
That means we could very much focus on the actual problems to solve rather than doing all this boilerplate infrastructure, pipelines, we had it under control pretty fast.
So as a result, we started to be in sync with the amount of work that came at us.
And we put some mechanisms in place to keep that in sync even better, which means that the speed at which we produce new features and new products, et cetera, et cetera, is very much on par with the speed at which the business can come up with new ideas.
So as a result, we didn’t have to scale the team because we automated as much as possible, a lot actually, probably much more than most companies can do because we’re not a super big company, right?
We, so that’s, therefore we didn’t need to grow the team.
Also on the other hand is that there was no churn because my team works with a very high level of autonomy.
So people can make their own decisions to do their own design, their own architecture within the guardrails that we have.
So people actually quite like it here.
So nobody left except for the first two months when the people who are already leaving left, right?
And, but nobody left.
And I, in the meantime, we grew the team with three junior people who are now fully merged into the team, but that was just over time.
And I haven’t been hiring or scaling.
A lot of companies, you see them, yeah, we need to scale up three to five times of whatever we are now.
And I always wonder why that is.
And I think that’s, but that’s my personal opinion is that most companies who need that scaling are making a mess of their IT landscape already, whether that’s architectural or whether that’s in code or not having tests or not having pipeline, whatever, right?
So it’s usually therefore that they want to scale, not because they need suddenly an explosion of new software.
So we haven’t been hiring at all actually in years.
So it’s not that we’re growing the tech team and that’s not just because of AI, but just because we don’t need it.
Yeah, but probably the sort of sum up that I take away from what you’re saying is we are not growing, but that is because probably throwing bodies at a problem is not the best solution anyways.
That’s sort of what I got.
That’s an excellent summary.
And that means it’s not necessarily something that is tied to AI because you made the point that it’s also about automation and the sort of, let’s say, traditional way that we should all be aware of how to build software effectively and efficiently and that you can do without AI.
That makes a lot of sense.
So here is a question from some anonymous LinkedIn user, at least it’s not shown here.
You were talking about the product engineer concept.
I have to admit that this was like, I don’t know, almost 20 minutes ago.
And the LinkedIn user says, could you elaborate on the product engineer concept?
Sounds interesting.
So can you elaborate on the product engineer concept?
Yeah, yeah.
So the way we were, so, okay, let’s start with, what’s a good story to tell?
Is in most companies, the amount of work that people require from their tech or IT or whatever you call it, is more than they can handle, right?
There’s always more work that we can chew off.
That means you need to prioritize stuff.
So we’ve put in place a bunch of mechanisms to where people from the business or even from outside the company, but that rarely happens, can propose new ideas.
So for instance, our COO says, we need to have an AI chatbot.
That was the example I gave before.
Or very recently we implemented Apple and Google Pay, just because it was posted as an idea.
And then we say, okay, so for every one of these ideas, what’s the business case for that?
So we give it a number in a number of months or a number of weeks or preferably a number of days, but we rarely do that.
And the business has to come up with what’s the value of this thing, right?
So if we do Google Pay and Apple Pay, how much more will we convert?
And you can express that in money basically.
And then there’s a group of people that we call the tech board, which contains all the major stakeholders in the company.
And every time we finished with one of these topics that was on the board that was voted for, and there’s room for a new one, we vote.
That means all the major stakeholders from the company agree on what’s the next item to pick up.
And as soon as it’s voted for, it goes into a column.
We call that the selected for development column.
And that’s where we come in.
So how my team operates.
Just a question.
So that would be a vote by majority or anonymous?
I’m not sure how you say it.
We discuss it.
So we sit together once a week and we discuss.
And then we say, okay, we have some room.
So what shall we do next?
And then it’s the head of finance, the head of marketing, and we talk about it.
So they all agree what the best way would be to spend the next chunk of time that we have available.
And that’s where my team comes in.
And everybody on my team is probably working on something.
And when somebody is done with it, with something they’re doing, they look at the boards and we have, well, two of them actually.
So one with the slightly bigger strategical item.
So they have to help us reach our strategy.
And the other one with the smaller topics, which are basically extensions to existing software.
And from whatever is in the selected for development column on any of these boards, they can pick it up.
And it’s up to the people in my team to pick up something that they want to work on, something that they want to investigate, to learn from, or that have done before.
They know the domain or could be any reason that they come up with, right?
So to give you an example, one of my female developers was pregnant and was going on a pregnancy leave.
And she said, well, the last couple of weeks I’m here, I’m not going to pick up any big items.
So I’m going to choose to do the smaller items.
And so everybody, depending on whatever they want to do, can make their own choice.
Even though I’m sort of like the manager of the team, I hate that word, I don’t manage much, but everybody can pick up any topic they like.
For instance, the fact that we are now, there’s a topic saying we should investigate having a public chatbot with a shopping assistant in it.
One of the guys on my team said, oh, I really want to look into that.
And so he says, I’ll pick that one up.
So the next step he does, or she does, depending on who is it, they’ll go talk to the person who proposed the idea.
So what is it you actually need?
And then they sit together and they work through it.
Meaning the people from my tech team, who are all developers, the developers and architects, because we all are our own architect, basically, go talk to the business themselves.
So there’s nobody in between, not a product owner or scrum master or product manager or manager, whatever.
They directly talk to the people who it concerns.
So there’s a very direct line between tech and the business.
And that means that we get the intent from, let’s say, our customer, which is our internal business, and then build it and then together with them, test it and walk through it and say, okay, then we need this and then we need that.
Up till the time that we have the minimal viable feature for that particular thing, we put it live.
And then additions to that go on another board, which means we might never do it, or we might, depending on what is voted for.
So it’s a direct connection between us and the business.
I mean, again, that’s pretty much best practices from agile, so that’s great.
And yeah, I mean, it’s often talked about, but seldomly it actually works, if it is actually implemented and it is done.
So that’s good.
Because that one question that comes to my mind is, so that means that the tech people pull the features and concerning, I mean, what they’re interested in and what they think makes some sense.
Now, at least in theory, it could happen that something that is very valuable is never pulled.
So is that a problem?
In theory, you’re right.
But that rarely happens because, well, it actually never happens.
Because we are part of the company, right?
So we’re invested in doing the thing that’s most worthwhile to the company.
And because, so there’s, the transparency is quite big, right?
So I sit in that the weekly setup with the stakeholders, I’m in there, people from my team are in there as well.
And then we talk about it the whole day about, oh, the business now really wants this and the business now really, and that was voted for, what do you think?
So there’s, the transparency is quite big, meaning people know why it’s important and why it’s relevant or why it’s urgent even.
Sometimes stuff is less relevant, but urgent.
For instance, there was legislation earlier this year in Poland, where if you do B2B sales, you need to go into a government system giving you some code that you need to put on the invoice.
Everything worked without it, but yeah, that’s legislation.
And we had to implement it before the 1st of April.
So that becomes urgent, right?
So urgent is also a good argument.
And then people from my team say, oh yeah, I’ll pick it up.
And they’ll do it.
They’re very, well, trustworthy in that sense, right?
And that’s also because we are a very close company, meaning everybody’s very close to each other.
And that team spirit is important for picking and doing the right things in the right way.
So there was a question on YouTube by Itzitsi, I think that’s the name.
And there was actually a typo in the question, so I’m not gonna show it.
And the question is, what would be the difference between an architect and a product engineer then?
Because you actually talked about architects and developers, or maybe those are the same people, I wasn’t really sure.
So what’s the difference between an architect and a product engineer?
We, so in my team, nobody has a specific role.
So that means all of us do all the work that is necessary to get stuff out of the door.
That said, everybody in my team has their personal preferences and their personal strong points and their personal weaknesses.
For instance, I have a very senior developer on my team and she doesn’t like to do front end.
So she usually tries to avoid that, which is okay.
And I have another person on my team and he’s the best infrastructure engineer I’ve ever worked with.
And I have a guy who’s on the forefront on everything that’s happening with AI.
And he usually takes us along like, see what I’ve now found and et cetera.
So everybody has their own particular, well, I’d say emphasis on what they like to do.
I, for instance, I like to tinker with our frameworks and I like to build our UI frameworks and stuff like that.
And other people are like, yeah, I’ll let him do that because he loves doing it and I don’t.
So you could say that the group of people together in my team, and we’re 13 people, have all the skills necessary to bring everything forward.
That includes UI, but it also includes architecture.
So that means that there’s people on my team and I’m one of those who like thinking about architecture, about the domain and the structure of, the structure of the whole domain and looking into DDD like stuff.
And other people do less of that.
So there is no, we’re not labeled.
So everybody can do anything.
That said, we have a whole bunch of guardrails when it comes to architecture.
So all of our services and all of our apps have the same server architecture.
So the same layering, the same patterns, the same way of talking to each other.
So all of that is very much standardized.
So that’s part of the architecture we rarely think about because it’s just there.
And every now and then we’re like, oh, we should probably improve on that or we should build a contract.
Let’s investigate to do contracts between the services and so we can pull it out of the central library.
So we have those kinds of discussions with the team, architectural discussions.
We usually have those on Thursdays when we’re all in the office, because we work in hybrid mode and that’s why we have these architectural discussions.
But there’s nobody, there’s no, let’s say no personal ownership to the architecture as well.
So we all contribute to it.
And if I look into my slide decks, we say we’re very lean on how we do architecture and everybody’s their own architect, which means everybody comes up with a solution given the guardrails we have that best fits the needs of that particular feature.
But I mean, if you talk about things like, should we have a contract between services, that is something that would be binding for everyone who of all the services and for the teams and for the developers.
And therefore it’s a different, I would argue it’s a different decision from just some code that you write that is just for one microservice.
Yeah, true.
So that’s the kind of discussion, oh, sorry, yeah, continue.
Okay, and then you just have a discussion and you come to some conclusion and this is how you make those decisions.
So it’s not that there is one person who’s supposed to make the decision or who’s responsible for that, it’s by sort of a committee or a group that would make those decisions.
Yeah, yeah, it’s by committee, which doesn’t sound, but it’s no, but it is what happens is that we save the Thursdays for these kinds of discussions.
And it’s not, so this team has been working together for six years and some of the people on the team I’ve been working with for nine years already.
And even there’s a guy on my team who I’ve been working with for like, well, 12, 13 years maybe.
So we know each other quite well, right?
So we know very well our thoughts and feelings also about architecture and we have a very open culture in the team.
That means that we can openly discuss and everybody who wants to contribute to that discussion contributes, it depends on the topic.
We have another meeting that’s actually a meeting, we call it Lean Coffee, which we have every Tuesday afternoon, where we do the same.
Basically, people put topics on a board that they want to discuss and then we vote and then we discuss for five minutes in the next topic or sometimes longer.
We also have those architectural discussions there as well.
And they can range from typical domain discussions.
One we had recently is about, we have offers and deals and they seem to grow very close to each other.
So we’re now considering removing everything that has to deal with offers and keeping the remaining part in what we call deals.
Deals is a part of our domain.
So we’re rearranging the domain.
So that’s more domain architecture, but also again, so we discussed, could we have, could we give our services a separate library that is separately deployed that exposes the types of that particular service so our clients can use that.
And clients could be other services or they could be front-end applications.
And that’s the kind of architectural discussions we also have with the team.
But in the end, we make the decisions as a team.
And if we can’t agree, then I’m usually the one that sort of cuts the cords, but that rarely happens.
And I’m just part of the discussion just as anybody else.
It’s a really nice way of doing things because it also allows people to grow in their knowledge and also in their ability to reason about architecture.
So also our juniors participate and they have the same voice as anybody else.
So we also have no difference between people, but we don’t actually have junior medias and seniors.
We’re all just there.
Yeah, I have to admit that I would argue that in the real world, often decisions are not, it’s not as clear-cut that one person actually makes the decision, even though officially that would be the case, because there is a discussion, as you mentioned, and then eventually everyone agrees what you, basically what you’re describing, that’s what should usually happen, unless there is some kind of deeper conflict.
There is a question by Riewik on YouTube, and his original question is, let me extend the previous question with this one, is it reasonable to preserve the roles and heights from the pre-AI era today?
And I would like to rephrase the question, because if I look at the discussion that we had, is there any impact on this discussion, like the roles, how you do the interaction with the business side and so on, is there any impact of AI on this?
Because it all seems, I don’t think you even mentioned AI in the last few minutes, when we were discussing these roles, so it’s not obvious, this question basically implies, okay, now we have AI, now the roles are all different, and to me, it’s quite the opposite, I had quite the opposite impression, what you’re saying is, or what I heard is, that there are these roles, this is how we do it, and I couldn’t see any relation to AI at all.
So, what’s the impact of AI on this?
That’s an interesting question.
So, we don’t have roles in our tech team, and I haven’t, I’ve been trying to move away with roles in companies that I work for, I’m a freelancer, so I occasionally switch positions, or I help coach other companies as well on the side, but I always try to stay away from role discussions, because role discussions means that people are gonna create their own territories, their own fiefdoms, and that removes openness from the discussion, I don’t really like that much, so we don’t actually have roles on our team, so everybody can do anything that they think will help the company, and whether that’s me, or the most junior person I have, so, but that was also before AI, so before AI, we didn’t have roles, and after AI, we still don’t have roles, we have our own set of skills, we all have them, and together that set of skills is quite complementary, and there was no need for roles, and there still isn’t, so for us, AI didn’t change the roles discussion, because we don’t have that discussion, in other companies, my honest take would be that also in companies that do have these very separate roles, which I try to avoid anyway, but I think there again, AI doesn’t change that discussion either, I think we are moving more into not writing code ourselves, I haven’t written a handmade line of code, well I do write one or two per day, but that’s about it, so we slowly move away from writing code ourselves, to helping a tool write code, so the specification language is not anymore TypeScript, or Java, or C sharp, or whatever language you have, it’s now in my case English, it’s less precise, but it’s good enough, so we move to a higher level language for specifying what the software needs to do, but that’s I think the biggest change so far, that doesn’t change the roles, we’re still solving problems, we’re still solving business problems, and that hasn’t changed, so I don’t think AI has a huge impact on roles, unless you have like 40, 50 different roles, then there’s probably roles that are changing or disappearing.
So I really like the point that you made, that there is now English, or German, or I don’t know Dutch, as the language in which you define what needs to be done, and one thing that I keep wondering about is, I mean this is something that a non-technical person could do, like someone who didn’t study computer science, and never wrote any code, so to maybe put it bluntly, why would you have developers then, is there anything that sets a developer apart from a business expert, that could also come up with these definitions in English, or in natural language?
Well, even more advanced, we actually have been trying to teach people from our business to write code, and some of them pick it up, some don’t, so there’s still a fairly large group of people in the world, that even with AI, is not able to build software, right, and I was listening to some talks at the conference, in Zadar, the SHIFT conference, where I was this week, and there were companies saying, yeah we are going to provide everything that makes it possible for non-tech people to have software built, let’s put it that way, so that includes roles and permissions, scalability, authorization, authentication, security, all that kind of stuff is now being put into platforms, so non-tech people can do this stuff.
Still now, we see that, I think that the dangers of everybody being able to write some sort of software, is that everybody now is actually doing this, very much to non-technical people.
I have actually people on our marketing team, who built their own IDE, marketeers, right, they built their own IDE, and that’s insane from, if you would have thought about this two years ago, that was unimaginable, but so now what happens is that people from the business come to us with almost fully working prototypes, which is the specification language that they now use, even instead of English, so they come up with the ideas themselves, look here’s a web page that does sort of what we do, can you put it in production, and there’s the difference, is that we know how to put stuff in production, we know about oh it needs to be multilingual, oh wait we need to use these frameworks, or we need to think about security roles, permissions, about where does it fit into the domain, how can we sort of keep the integration together between all these separate tools that people are building, and that’s our work, that’s what we do, so for now I think that we’re going to keep on doing this, and transforming prototypes into actual working enterprise software, and there’s still a big difference, whether that’s enough to keep us relevant, I don’t know yet, but that’s what the future needs to point out, but that’s, it’s almost impossible to predict where we’ll go with this.
Yeah, I really like the idea that you say, I mean in a way what you said is that business experts are able to write prototypes, but it’s different from stuff that goes in production, and that’s the difference, I think the difference between software engineering, and what business people can do, yeah, so that’s great.
There is another question by Riyavik on YouTube, or a comment rather, so he says, I think we, why we still have the roles like developer, engineer, PM, PO, etc due to accountability and responsibility for what we deliver.
Okay, I mean if I, yeah, if I look at what you’re saying, or how you’re describing the organization, it seems that the responsibility oftentimes is about a team, like for architectural decisions for example, and therefore it’s not pinpointed to a single role, or a single individual, but rather to a team, obviously in the case where a product engineer would develop some stuff, it’s their responsibility to do it, and that would be just one person, but otherwise it’s a shared responsibility, so I’m not sure whether the comment applies to what you’re saying.
Well, I think so.
I think that what we’re doing is very much on the forefront of how you can work together, right, and that’s, and our ways of working have evolved to over time, right, so like, if you would ask me 15 years ago, then I would have said, yeah, or maybe 10 years ago, you definitely need a product, or a product manager, or whatever, and somebody who’s accountable, and I think the responsibility now is with the people who come up with the feature, so that’s, in our case, the people from the business directly, so if we implement Google Pay, it’s the finance manager that is responsible for the fact that this thing goes live, so he’s responsible for figuring out what we would actually need, or in most cases, it’s the marketing department, so the marketing manager needs to take things into account, or we do stuff for our content department, and it’s their feature, right, and we build it together with them, and they are going to give the final approval, and that’s for every feature that we do, so it’s a shared responsibility between the sub-team of my team that implements something with the person from the business doing that, that’s a very direct way of doing stuff, and we do that specifically because speed for us is very relevant, if you go into an organization that has 300 teams, like if you work for a large bank, for instance, or even a large e-commerce company, they have a lot more, let’s call it enterprise-y things in place in their ways of working, which we don’t need, that’s, for me, one of the reasons I don’t want to work for very large companies, because the amount of, well, let’s call it red tape, is not something I really like, I did that for a long time, I worked for large consultancies for 20 years, they work for large customers, and that’s all fine, but I’m not in that world anymore, so for me, those roles have disappeared.
There is another comment also by the same person, that goes back to a discussion that we had before, concerning the SaaS providers and the people who work on standard software, and what he says is, I think the traditional enterprises like Adobe, where I work at, Autodesk, Atlassian, et cetera, or SaaS providers in general, have to update their organization structures, rules, and worker skills if they want to survive, and to me, okay, because what I heard when you were talking about those companies is that they just don’t have a product anymore, and what you seem to have said, or what I heard was, okay, we are not using these SaaS anymore, because we can just build it ourselves, so no matter how they change the roles in their company, if they don’t change the product, the problem won’t go away, and that seems to be something different, right?
The question is around, should we reorganize, and it seems what you’re saying is the problem is the product and the market.
Yeah, it’s combined, so what I see happening is that a lot of the SaaS providers, and again, a lot of the SaaS providers, especially in the AI space, like we have an AI for this, an AI for that, and we look at it like, yeah, so what?
We can build it in two days’ time, and we’re not the only ones, right?
So that means that a lot of them, especially the smaller companies, unfortunately, that provide a particular service to other companies, mostly B2B, I would say, are going to have a very much diminishing set of clients.
I’ll give you two examples.
We get a lot of invoices from the people that we buy the products from, vendors, suppliers, whatever, right?
And those invoices, they need to be handled, which means we had invoice recognition software that does OCR stuff, which is kind of complicated and very expensive too, because for every different supplier, we had to set up a template that fits their documents, so the OCR software could read those documents.
And about a year ago, we set up where we’re like, yeah, but we pay an X amount of money to have this tool in place, which still creates a lot of work, because it can only read through.
So for every company, every supplier, we had a template, we had to create or had to create a template, and we’re like, what if we just use an AI to read the invoices and get as much information out of it and then give the rest of it to our finance department so they can fill in the remaining details?
We built that.
It took us two to three people, depending on where we are in the process, and it took about two months to build the first version, and after three months, we had a version that replaced about 70% of the workflow that we originally handed off to this external company.
So we stopped the contract, right?
We have done our own invoice recognition, and it works quite nicely now.
We haven’t touched that in a while, and there’s probably better AIs that support it now, but those we can build in-house.
I’ll give you one more example.
There’s a company that does translations, and we use that for translating our content, translating commands made by customers, etc., and we pay them a lot of money.
Then we move to AI-generated content, AI-translated content, which means our bill with that particular company went from 6,000 euros per month to, I actually approved the invoice yesterday, to 280 euros, right?
So that difference in money needs to be accounted for in those companies, which means they don’t have the money to pay large amounts of people to keep that company alive.
It’s the same that you will see with the Atlassians of this world and all the other service providers.
They’re going to shrink, basically, due to AI.
Okay, but I mean, when you started talking about these two examples, you said that it’s not just that the product is dead, but now you gave, or that’s at least what I understood, you gave two additional examples where the product is sort of dead.
So is there anything that those companies can do in terms of reorganizing internally, having other roles, or, I mean, it still seems to me that what you’re saying is, well, come up with some new product, otherwise there is a problem.
Well, I think that a lot of companies in this space, in the SaaS space, will see that there’s going to be diminishing returns from their products, and to a large extent, because everybody is now thinking, oh, we can build this ourselves, right?
So as a result, there’s going to be less income.
As a result, they’re not going to be profitable.
A lot of them are not going to be profitable anymore, if they ever were, which means they either vanish or they reorganize.
And that’s not going to be nice for a lot of companies, let’s put it that way.
Unfortunately, because there are also nice people in nice companies.
But we looked at our confluence bill yesterday, which is our wiki for keeping content, and we’re like, how much do we actually still use it?
And for the few cases that we use it, why don’t we build it ourselves in a couple of days?
And if you only use a few features of a particular product, then you could easily rebuild it these days, right?
And it doesn’t even require tech people.
However, if you are a user of 100,000 features, and you have your full tracking in place on everything and whatever you do, like large enterprises do, then you’re probably still relying on JIRA for the rest of your lives.
We’re not going to do it.
I think we’re going to remove away from those kind of tools too.
Tools that two years ago were so standard that you never thought about not having them.
And now we realize we only use a small portion of all the features that they offer.
So why would we pay all this money for it?
And we’re not the only ones thinking like this.
You see this everywhere.
So final question from Mark Dehaan on LinkedIn.
Big thing I’m wondering is about the number of people who do this, who know how to put stuff in production.
That is about, you know, the difference between engineers, product engineers and business people.
And the question is whether the number of those people who know how to put stuff in production will increase or decrease in the coming years.
Trends that I see seem to be pointing to a reduction, but that might mainly be a macro development.
So what do you think?
Are we going to have more or less people who know how to put stuff in production?
Yeah.
Hard to predict the future.
Yeah, that is tough.
But what I see is that, so one of the developments we are doing currently is we are building a, let’s say, let’s call it a sandbox.
We call it a sandbox where everybody else in the company can do, can build whatever they want to build based on top of the APIs that we put available or APIs from external parties so that they can build their own dashboard and their own simple software or whatever, right?
But that needs to be safe within the boundaries of iBOOD.
So we’re now building the sandbox so people can do that.
And I think the enabling of people who have no idea how to put stuff in production is going to be a larger part of the work we do.
So we as tech people have to enable people to write software safely and not just deploy it on Vercel with a Postgres database somewhere in the cloud protected by a dashboard called Peter123 or whatever you might use, right?
So I think that’s going to be part of our job.
Does it require a lot of people?
I think it requires very skilled people.
But I’m not quite sure whether we require the same amount of people.
I think we probably need less people.
But there’s a counter side.
I’m sorry.
Yeah.
No, go ahead.
The other point is, if I consider myself a product engineer right now, I can also become a domain expert.
So that would be the other option to me.
The question sort of said or could imply, well, I’m now a product engineer.
Will I have a job in some years?
And the answer might be, okay, if you change to the more domain side of things, maybe you have, and maybe that’s an option to do.
And I would even argue that has always been.
It doesn’t really understand the domain at all.
So I have to have a different skill set.
I can’t specialize in the domain.
That doesn’t make any sense.
True.
True.
Yeah.
Yeah.
I’m not.
So I think, but that’s probably a more architectural point of view is that what we can still do, let’s call us as the product engineer, we oversee the whole thing, right?
The whole platform, the whole domain, the whole landscape, whereas users from a particular department in our case, like finance or marketing or logistics, or they mostly oversee their own part of it, which is just a small part of the domain.
So we have to take care of that.
Everything still works together.
And that’s part of being product engineer, product architect, whatever you might call it, that people from the business are not going to do.
So in that aspect, and that’s a large part of it, that’s called domain engineering, domain design, that is very much still part of our work.
Because we know when we register a claim to where it sits within the orders and the offers and et cetera, et cetera, and people from the business rarely oversee all of them.
And that’s okay, right?
They do other stuff.
Yeah.
So we have actually done quite some overtime today.
So thanks a lot for answering all the questions.
Also, thanks a lot for the discussion in the chat.
I think that’s about it.
I’m not sure whether there are any final remarks that you want to make.
No.
So what I basically say is, there’s one thing that I always have in my slide deck is called the just sharing principle.
And that says, the stuff I’m telling you about is the stuff that works in our context.
And I’ve very much realized that everybody else’s context is very different.
So stuff that sort of eliminates this question like, no, that will never work for us.
Yeah, that might be true.
But that’s what I just said.
So it’s like, there’s nothing that works for everybody.
And that’s good because that keeps it fun.
Yeah.
Thanks a lot.
I think those were excellent final remarks.
So thanks a lot.
Thanks a lot for taking the time.
Thanks a lot again to the audience for the questions and the discussion.
And hope to see you at the Software Architecture Gathering.
As I said, there is a rebate and we’ll meet there.
So thanks a lot and have a great weekend.
Thank you.
A note from our team.
Hello, Software Architecture Stream listeners.
My name is Lukas and you might know me from some episodes here.
I will start a spin-off podcast called Maschinenraum, which will focus on web developments, operations, and design.
You will hear the first few episodes on this channel.
But if you don’t want to miss any episodes in the future, you can already subscribe on maschinenraum.fm.