Do you hate legacy or do you love it? Do you accept it or do you want to stamp it out? This time I talk to Nico Krijnen (Lumunis) about the opportunities we have in our legacy codebases to understand our business better, the strategic use of new technologies to make important product improvements, the importance of collaboration and visualisation to create a shared vision of software architecture and our product no matter what state the codebase or architecture.

We discuss the meaning of legacy, what it is and when it appears, how to fix it, how to avoid it and how to prosper as a business while replacing it. We also talk about what you can do in your pipelines to avoid legacy automatically, the importance of visualisation, context mapping in DDD and C4 diagrams.

In a fascinating and wide-ranging discussion, we talk about what it takes to make great software in the age of microservices.

NOTES

The DDD NL meetup:

https://www.meetup.com/domain-driven-design-nederland/

Nico's workshops at DDD Europe:

Full-day workshop on June 6:

https://dddeurope.academy/applied-eventstorming/

2h hands-on at the main conference:

https://2023.dddeurope.com/program/playing-with-domain-models-in-code/

Automating architecture validation for Java and .NET:

https://www.archunit.org/

https://archunitnet.readthedocs.io/en/latest/

With an example of using it for a layered or onion architecture from one of Nico's workshops:

https://github.com/nkrijnen/workshop-apeldoorn-jug-2022-11/blob/main/part-01/src/test/kotlin/eu/luminis/workshop/smallsteps/ArchitectureTest.kt

Nico's speaker profile & linkedin:

https://sessionize.com/nico-krijnen/

https://www.linkedin.com/in/nicokrijnen/

And an overview of some of the courses Nico gives through Luminis:

https://www.luminis.eu/expert/nico-krijnen/

QUOTES

[01:41] "it seems that in our industry, only seniors and architects, et cetera, are getting in touch with domain-driven design at some point and I think that's a waste" [NK]

[02:10] "so one of the things I really wanted to do is trying to lower that learning curve [for DDD]" [NK]

[04:03] "you need to have ways to create sort of a shared mental model of the stuff you're working on" [NK]

[05:02] "We had a chat the other night about, how we feel about Legacy. I said, I love it and you said, I hate it. How does the legacy fit into to your daily work?" [RB]

[06:20] "legacy can have a lot of bit different meanings, but typically it means something that's not, at least how I see it, is it's a code base or a product that's not easy to work with anymore." [NK]

[06:38] " I like to go fast. I like to, to build stuff and, and be excited about those things and not feel dragged down by, a big stone that you're dragging along." [NK]

[06:47] "that's why I hate it [..] but to be honest, all our industry is full of it" [NK]

[07:03] "a lot of teams do not have the discipline to then go fast, but also go quality" [NK]

[07:45] "So typically when you meet a legacy system, first of all, what, what are the smells of its legacy? And secondly, what would you start to think about doing to improve that situation?" [RB]

[08:59] "we got someone in and they started working fully automated regression test, so deploys to production could be done, [in] half an hour. So that's different from a week, right? " [NK]

[11:16] "Cause it's a system that's making money, right? This legacy system is the place where, where you, where your business runs on." [NK]

[11:55] "So, I still hate working with legacy, right?I refuse to accept it. I think that's more than mindset, right? So I refuse to accept it as legacy." [NK]

[12:50] "You can transform that into a modulith like, which is, uh, what you call it nowadays." [NK]

[14:09] "So that's also why I think why I'm talking at conferences and spreading this knowledge because I think it's important to help the industry to realize this and also to find ways to get [legacy] under control" [NK]

[14:23] "We're building more and more software and, if we're not doing it the right way, we're just building, a lot more legacy. And I don't want to be there!" [NK]

[15:06] "I think the ease with which organizations now adopt Kubernetes and under underestimate the complexity, [is] quite scary, to be honest." [NK]

[16:46] "I think in a lot of cases people underestimate the value of just sticking with the stuff that you know and can handle" [NK]

[17:34] "Because I think a big portion of legacy is that people don't understand how the system works or what it's supposed to do, or at least do, or pieces of it." [NK]

[17:49] "I think that's where domain driven design, again, has a good role to play, is that it helps you to understand a domain. It helps you to understand the problem space." [NK]

[18:24] "it's good to use some experimental technology to do something that nobody else has ever done because it's gonna put you in a space where nobody is and where you can solve problems that nobody else can solve." [NK]

[19:56] "I would try to take the Frankenstein out of it, not accept that it's a lost cause." [NK]

[21:00] "[Legacy] is usually the point where people don't understand how a system works anymore" [NK]

[22:25] "In the workshop you encounter something that's called an Arc Unit, which allows you in your pipeline check or you compile time or test time, check that the architecture that you have in mind is not violated" [NK]

[24:08] " I think is always super important to have at least one visual in your, in your project" [NK]

[24:53] "try to write the minimal amount that you can, right, that you need, but that you are sure that you can keep up to date over time" [NK]

[27:43] "the real value of that kind of high level diagram is not so much having an up-to date version of it. Is it It is drawing it together with the people working on it." [NK]

[29:11] "giving context , about a system, what I think is really useful to draw a context map like from DDD, which essentially is like the high level context overview of, a system, but then more focused on the communication patterns between systems and especially also between teams" [NK]

[30:24] "a high level C4 diagram and a context map" [NK]

[31:05] "The temptation is always for everybody to prove their worth on any project" [RB]

[31:50] "we don't want to get the impression [of domain driven design] that it means you start to do a lot of design upfront." [NK]

Hello and welcome to Loving Legacy.

I'm your host, Richard Bown, and this time I'm joined by Nico Krijnen.

Is that right?

I said it right.

Yeah, that's totally right.

Thank you.

Um, good to meet you.

Good, good to meet you again.

Maybe you could introduce yourself to everybody and, um,

then we can discuss our topic.

Yeah, that's fine.

Um, so I'm Nico and I've been working in the software industry for a while.

I've been doing a lot of product development, let's say development as

part of a product for quite some years.

Had a nice experience of going from absolutely, uh, nothing to

a good working product with a lot of, , people using it worldwide.

That was really cool.

Journey.

Also being in somewhat bigger companies in, uh, what they

call the servant leadership role.

But I really also have a deep technical understanding.

Your background, is development though, would you say?

on the,

uh, developer.

. So my view is always very broad cuz I want a complete successful

software solution on the whole.

So, um, I need to know a lot, a lot of stuff on a lot of different topics.

Uh, but the field's just too huge.

You can't know everything.

So, uh, but still I'm surprised sometimes how much I know on specific stuff anyway.

Okay.

And you work for company called Luminis, is that right?

Yeah.

It's, uh, consultancy in, uh, Holland called Luminis.

And then Luminus as a whole is a bit bigger, so you also have a lot

of other colleagues who are pretty much all of them very smart people.

So, uh, there's a lot of people around you that you can, uh, lean

on and I think that's really nice.

Uh, combination.

and we met first, uh, end of last year, I

think November, December time.

There was a domain-driven design, uh, workshop.

So you, you organized the meetups as well, you, for DDD nl.

Yeah.

I knew about the meter for a while and I was always interested in DDD, because

I think there's a lot of value in it.

, it's somehow it seems that in our industry, only seniors and

architects, et cetera, our level are, are getting in touch with, uh,

domain-driven design at some point.

And I think that's a waste because there's a lot of value in there that also, uh,

juniors, et cetera, could benefit from.

They just didn't encounter the problems yet that, uh, that you need DDD to solve.

That is useful for pretty much everything you do.

so one of the things I really wanted to do is trying to lower that learning curve.

. The workshops really to help people experience firsthand what kind of

things you can do to take small steps.

Making that big change and to force yourself into a mindset, into a way

of working that helps you do that.

No, I love, I loved it.

I really enjoyed the workshop.

I went along again this week and again, I really appreciated the effort that was put

in there because it was, as you said, and you, he mentioned something that you just.

Said as well, like about how a lot of the time, the terminology or

the, yeah, don't mention dDD I think is, was part of its closing words.

Yeah.

Because it does tend to put people off because there seems

to be this kind of idea that the learning curve is quite steep.

So we might come across it as a software engineer day to

day and overcome it somehow.

But when you see it written down, you go, oh yeah, maybe that's a

big problem that I'll come into.

Where can I fit this, fit this into my way of working?

Yeah.

Whereas probably you already, you've already experienced this a bunch of time.

But yeah, if you don't know all the terminology, then you don't recognize it.

And then some of the ways stuff is described stays very abstract.

So then I make it very concrete by just letting people experience it in code.

So yeah, you mentioned visualization there as well.

We, through event storming and we talked about the other night

things about example mapping.

Um, and we did some domain modeling or pieces, pieces of these,

um, These are aren't activities that you do by yourselves.

They're really all about collaboration, aren't they?

Yeah.

Because, uh, in the end, software is getting more and

more complex these days, right.

And the time.

That, and I'm sure you, you were in that time as well, right?

Where we could just write pieces of software all by,

yourself, and it would be fine.

That time is long gone.

Right now we're building, uh, distributed systems with, uh, multiple people, with

multiple teams working on pieces where the cognitive load of all the technology that

we talked earlier, earlier about, right?

It's too much for one person or even one team to handle.

Uh, so you need a lot of collaboration to get stuff done, and it also

means that you need to have ways to create sort of a shared mental

model of the stuff you're working on.

Um, not just on technology, uh, but also with like domain experts, people who know

how uh, the problem that you're solving could be solved or what the problems

are that you may wanna, uh, solve or how something works in that domain.

Getting all the knowledge together, is a big challenge, because in the end,

right, a lot of engineers talk a different language than people who work in a certain

domain . So, DDD provides a lot of good ways to write the concept of a ubiquitous

language, of bringing that together.

And, uh, event storming is one of the, I think, very approachable ways to do that.

But there's many, many more collaborative ways of doing that.

I think it's really good to, uh, to put more and more focus on that and

just create more and more tools to allow us to do that, uh, in a good way.

No, absolutely.

Um, okay, so this podcast is about Legacy and about Loving Legacy, and

we had a chat the other night about.

Yeah.

we feel about Legacy.

Because you asked me, you said to me, so yeah, what's the name of it?

Oh, legacy and I, I said, cause I love it.

And you said, oh, I hate it.

That was your response.

So yeah.

So how do you see that?

So what's the, yeah.

How does the legacy fit into to your daily work?

I mean, the best times I've had writing software was always

when you're just write, when you're thinking of new stuff, when you're

writing new stuff, , somehow that feels the most productive and especially when

doing it with, A team of people, right?

With different skill sets.

So you combine these skill sets and you create, you get this sort of

magic where you can create stuff that you could never do yourself.

So I think that's, that's, uh, really nice to be in such a situation.

And when you get into a situation where there's a system with a lot of

history and started it somewhere, and then, obviously still, uh,

being involved in it, uh, later on.

Um, but a lot of people joined that project throughout the

time, and obviously it's not.

At the start, it's your baby, sort of, right?

And uh, and you have total control over everything.

And you can put your vision, your ideas in there, and then a bunch of , years later,

your vision changes, your ideas change.

So you have to bring that along.

You have to be very disciplined and very structured to make sure that it

stays in a, sort of, in a good shape, but at some point, , if you don't

do that, it becomes legacy, right?

And, uh, legacy can have a lot of bit different meanings, but typically it means

something that's not, at least how I see it, is it's a code base or a product

that's not easy to work with anymore.

You don't like being in it, you don't, uh, feel like it's, uh, you are getting

stuff done at, at the pace that you would like to get stuff done, right?

I like to go fast.

I like to, to build stuff and, and be excited about those things and

not feel dragged down by, a big stone that you're dragging along.

So, , that's why I hate it, right?

, And that's really why I don't want to be in the situation.

But to be honest, all our industry is full of it, right?

Because there's so many places where we are trying to go faster and faster

and agile and faster, faster, and I think the big problem is that a lot of

teams do not have the discipline to then go fast, but also go quality, right?

And you have to have.

Both of those because the moment you let slip of quality and that control and

architecture and all those kind of things, , you end up in legacy very quickly.

So even if your, your idea is, ah, let's just rewrite because this, this stone

is so heavy, we can't lift it anymore.

Let's just, uh, start from scratch.

It sounds very appealing, but in a lot of cases, If you don't do

something about your mindset and the way you're doing that, you're just

gonna end up with another stone and you're dragging around two stones.

Okay, so a couple of things there.

First of all, you said the quality is, is important.

So I was gonna ask about your approach.

So typically when you meet a legacy system, first of all, what, what

are the smells of its legacy?

And secondly, what would you start to think about doing

to improve that situation?

Yeah, it depends very much on the situation, but, let's say last

year I was in a a place where, uh, a clear smell that I've picked up, right?

Because I just jump in the project and I, I look around and to be

honest, I wasn't there to fix the legacy but I smell things right.

And then, uh, one of the things I smell, it's okay.

This, this team is using a branching strategy that's way too complicated

for what they're trying to do.

There were two developers and they were having working on

three releases at the same time.

That's just, totally crazy.

Uh, and it was a, there was also a lot of meetings and stuff around it, right.

To organize what goes into which release and then never to re branch and re

well, lots of, lots of wasted work.

So then I go in and I say, okay guys, let's not do this.

Let's change the way we do that, do things.

Let's just move gradually Right.

Towards a more trunk based way of working.

Cuz it's just.

Two developers there, even if we're gonna add more later, let's try and get there.

But we need stuff to make that happen.

So one of the things they really needed is to get, there was sort of a

manual testing cycle that took a week.

Uh, so, uh, we got someone in and they started working on a, uh, test automation

suite, which took a half a year Right.

To get that in place.

But at that point they had a, uh, let's say fully automated regression

test, so deploys to production could be done, let's say after that ran,

which was, uh, Well, half an hour.

So that's different from a week, right?

So you, you, you change the ball game completely.

at that point you get to into a very different, flow of working and

things start to go fast again, right?

So it's the way you work.

So it's a branch strategy, but it was also, the way the pipelines were set up,

it was also the way the testing was done.

Cuz there was good unit testing, right?

But this.

It wasn't enough to give confidence that the thing is actually gonna work.

Cause they were having issues with stuff going or breaking every time.

. Also because of the complexity of the branch strategy, not knowing what

you're actually putting into production

so there's just one example, right?

But there's just so many, many others.

I mean, I remember that, um, in another early project we

had to replace Elasticsearch.

And we were, still using a very old version of that.

Uh, just, uh, didn't get, uh, get around to upgrading it because

somehow it wasn't important as all the features we're building, right?

Because we couldn't upgrade our spring libraries anymore because the spring

data library we use for less search couldn't be upgraded cause it couldn't

talk to the old version anymore.

So you sort of get this cascade of things that are holding you back.

We couldn't upgrade the Java version because of that.

There's just so many things stacking on top of each other.

So we just knew, okay, this, we have to tackle that thing, but

it was gonna be a big change.

Right.

It's not an easy upgrade.

But we just did it.

We all, again, took half a year to do that, but we kept the whole

system working all the time.

We had zero downtime deployments all throughout.

We did deployments twice a week pretty much.

, so we did that whole migration, but in such a way that we could essentially

get the whole new variant up and running and, and ready and test it, et cetera

before we do the actual migration of our production, uh, environment.

Uh, and it also meant that, because a big problem with these kind of

big changes is that while you're working on the big change, which

is gonna take half a year, right?

Somewhere halfway, there's gonna be a super high priority business thing that

comes by and it means you have to go back and work on the, the actual features.

Cause it's a system that's making money, right?

This legacy system is the place where, where you, where your business runs on.

So.

You have to, to do stuff on it.

Right?

Keep it relevant to your customers.

To be honest.

We did the migration within, uh, the complete migration we did in 10 minutes.

But we just prepared the whole thing in such a way that we could do that.

And that works.

Wow.

Okay.

Well, the, the two examples you gave a lot of your work is actually handling.

Legacy in some way, in some form.

Either improving it, um, or improving a process around it, or having to

build something which, which has got a legacy component already.

So not like that in that last example.

Yeah.

So, and I still hate, hate working with legacy, right?

But, refuse, uh, I refuse to accept it.

I think that's more than mindset, right?

So I, I refuse to accept it as legacy.

, if it's there and sometimes the decision is to, uh, to rewrite it, right?

If you can do that, , and.

The trade works well for you, then that's the way, uh and that's also

the way I do it in some cases, right?

But in a lot of cases, you just have to, uh, to make the legacy not legacy anymore.

Um, and that means bringing in discipline, bringing in ways of working,

that you do stuff in small steps.

And even on a, on a big people call it a monolith, right?

You can transform that into a modulith like, which is, uh,

what you call it nowadays.

in a lot of cases just creating a good modular system.

That is, even that is just one deployable unit or maybe two or three, right?

If you need some scalability in some places, um, is way faster

than all these other things.

And then creating all small microservices

something I was gonna say.

Yeah, I completely agree with you as well.

I think that's absolutely spot on.

You've gotta pick your horse for your course, essentially.

Um, however, there's a couple of things there.

Um, first of all, it is kind of inevitable these days that people

wanna build on the Kubernetes.

They wanna have stuff's CV based development essentially.

So a lot of the time where companies make a decision because it's gonna be,

it has to be the latest technology to attract people to that particular way.

Secondly, the around the way of working.

So you mentioned in order to create or get rid of legacy or control legacy, you

have to be very structured in the way you work, but also you need to be structured

in the way you work anyway, essentially.

So it's kind of, it's not creating, legacy is being structured

as well as fixing legacy.

So it's the same approaches essentially just from different balls

of mud or scales of ball of mud.

So I think if you work on something new, you, you

should also always, do it in that way, uh, as well, probably, right?

Because, uh, otherwise you're gonna end up with, with a legacy, which

you don't want to be, want it to be.

But still in our industry, I mean, how many places do you see that

do not have some legacy system?

I think as an industry we're, we're still definitely not in control here yet.

Um, and there's a lot of.

Knowledge right.

On how to do these things better, but somehow we are not managing to apply it.

So that's also why I think why I'm talking at conferences and spreading

this knowledge because I think it's important to help the industry to

realize this and also to find ways to get it under control, right?

And help people get it under control, , because, um, , we're

building more and more software.

And, if we're not doing it the right way, we're just building, a lot more legacy.

And I don't want to be there.

I don't want to work on more legacy, right?

At the same time, there's all these nice shiny little toys out there.

And we're still engineers.

We like playing with, with toys, at least I do.

Um, and, uh, the latest and greatest stuff is always better than the old stuff.

and in a lot of cases these new toys, uh, Are created to solve a problem, right?

Kubernetes is there to solve a certain problem as well.

Uh, I just don't think it's, it's there to solve every problem.

I mean I've, I've worked with it and there's definitely a lot of

value in, in the way stuff is there.

Um, it's also way too complicated for a lot of environments, I think.

Right?

I think the ease with which, organizations now adopt Kubernetes

and under underestimated complexity, I think that's quite scary, to be honest.

Um, especially if you see how cloud vendors are actually taking a lot

of complexity away from you and how you're trying to get it again.

Right.

Uh, on the other hand, you, you sort of are in control of, of a lot of.

Areas, at least it may feel like that.

Uh, so that's, um, I always like to be in that situation as well.

Right?

I mean, I remember that, um, when we built that, that product that I was

talking about long ago when we started on that, uh, one of the big things that

I really liked, Or the, the good choices I think we made is that we actually

took everything under our own control.

We didn't depend on third party vendors or anything to, uh, to help us.

We made sort of a buy versus build decision at early on, and the, the first

time we did, okay, we'll just buy part of it and built another piece, and later

on, yeah, that vendor was just, you know, the whole industry in that area wasn't

moving at the pace that we needed, so, We changed the decision and we said,

okay, we're just gonna build everything.

Uh, so we control everything and control the evolution that we need.

Um, and that really, uh, played out very well for us at that point.

Right.

But as a, it needs to be a conscious decision.

And I think in a lot of cases now, people are making decision based on

whatever is shiny or whatever vendors you're talking about or, or whatever

consultants are talking about.

Oh, I think it was always been like that, hasn't it?

Yeah, it is.

Right.

But, uh, that's not the, that's not the way it should be, right?

Uh, you, you should make, uh, trade offs based on what you really need.

But yeah, that's really hard always.

I think in a lot of cases People underestimate the value of

just sticking with the stuff that you know and can handle.

Uh, and that means less shiny, less toys, but stuff that you can move

fast with and that is, I think, usually quite underestimated.

I'm, I'm suddenly thinking.

This is, you are almost describing legacy, but it's kind of optimized,

so it's like a, you've gone through the process of improving your system.

Everyone understands how it all works.

Once you've got an optimized legacy system, essentially that's the

sweet spot in some ways because you could, everyone's familiar with it.

They know what the tools are like, they know how to extend it, and,

and it's also simple to deploy and it's easy to, to get releases out.

Yeah, but that's not how people experience legacy, right?

So I think if you take the word legacy out, but say a well organized, structured

system that people know and understand.

That's not legacy, right?

Because I think a big portion of legacy is that people don't understand how the

system works or what it's supposed to do, or at least do, or pieces of it.

There are, very good reasons for it.

Using new technology on certain stuff.

you really need to understand the, the field, and I think that's where

domain driven design, again, has a good role to play, is that it

helps you to understand a domain.

It helps you to understand the problem space.

And once you understand that, that really helps you to, um, to make better decisions

about the stuff that you're gonna do.

And maybe.

Right.

And I think also combining product thinking with domain-driven design

is really powerful space that's being explored by the community at the moment.

I think that is even more powerful because then you're also starting

to, uh, think a lot about, okay, what's important for our users?

Even makes the decision more targeted and then maybe there are cases which, cause

I experienced them, where it's good to use some experimental technology to do

something that nobody else has ever done because it's gonna put you in a space

where nobody is and where you can solve problems that nobody else can solve.

And obviously that's a, from a business point of view, a very good place to be.

So, If technology helps you there then maybe that's the the

thing you have to do, right?

But then you have to be conscious that it's gonna be a trade off, right?

It means you have learning curves.

Or you make it an experiment, you just say it's a mark.

It's almost a marketing experiment.

You throw it away.

So if it doesn't work, fine, we, we, we move on fast.

A lot of problems in those cases, right?

Is that you, people don't throw it away, right?

It's, uh, it's a marketing experience, uh, but then it's somewhat successful

and just lingers on and becomes another legacy stone that you have to carry along.

Yeah, that, that links onto to a nice point, um,

around exactly that exactly.

Attempts to fix legacy.

You must have seen this as well, where people have kind of come in and

say, oh, this is a, like a monolith.

We need to split it up.

And suddenly you end up with a monolith plus a couple of microservices,

plus some other pieces in an attempt to do the right thing, but not.

Carrying it through.

I've seen that.

I'm sure you have too.

Yep.

It's in that, at that point, you're kind of

screwed both ways, aren't you?

Because you kind of, you can get, you can get a system into a point where

you can't really go anywhere with it.

You and that point, you have to just throw it away or just leave it, you know,

because it becomes a bit of everything.

It's a Frankenstein.

Yep.

yeah.

How would you approach that?

Well, I, again, I would try to take the Frankenstein out of

it, not accept that it's a lost cause.

And sometimes it is, right.

You just have to throw it away.

But to be honest, I think in a lot of case, people don't realize that you

can still make it work, But you have to then probably make sure that you

start, rewriting the parts that really nobody understands anymore, get the

team like the, and the domain experts together and have them solve that

piece together so everybody understands that part of the software anymore.

And then you probably don't need the old part anymore and you can turn

it off and you only have to pick out pieces of that legacy part and,

uh, and chop away at it bit by bit.

Just go back into that for one minute because, uh, you defined

a legacy system is something which.

Is not supportable anymore.

Is that right?

No, it's a, there's a bunch of definitions, right?

I think Michael Feathers has a nice, nice one where he says, yes, a legacy system

is just a system that doesn't have tests.

Um, that I think in a lot of cases that's the case.

Yeah.

A lot of peop systems without tests, uh, become legacy, but

it's not necessarily the case.

What I've seen so far, it is usually the point where people don't

understand how a system works anymore.

Uh, and it can have a lot of reasons, right?

Can be because there are no tests.

Cause then, uh, or because the tests that are there are really poorly written,

in some cases, it's because the people with the knowledge about the system

left or, some new people joined that have a very different idea about what it

should be, start changing it and then.

Only do the change halfway you could say.

So you get sort of two systems or two different ways of working in, in one.

That's also what, what we talked about earlier.

System nowadays are very complex, right?

Distributed systems where multiple people are always working.

Uh, this is not just one person working on it.

This consistency is very powerful to have in a system, but it's also

really hard to maintain, right?

So you have to be very disciplined.

Um, And, um, I've been in the situation.

Why did the system that I once built, uh, over the years, it, it wasn't

the system that I built anymore.

Also, it didn't follow the principles that we set out at the start.

I mean, we wrote all the documentation about, uh, architecture principles

and those kind of things that we wanted to follow, but new people

join and at some point there's multiple teams working on it.

And, uh, There's is no way you, you can completely control that,

especially if you try to do it like two things as documentation.

Cuz yeah.

Whoever finds and reads these things anyway.

So I think one of the things that I'm also trying with these workshops is automate

a ways to enforce these things, right?

So, , in the workshop you encounter something that's called, uh, arc Unit,

which allows you in your pipeline check or you compile time or test

time, check that, uh, the architecture that you have in mind is not violated.

Uh, so these kind of things really help to also help juniors that

started on a, on a project or even other, uh, other coders that have

a different idea to, to understand why these things are there, right?

Because there is something that will prevent them from, uh, building that

version of the code if they, if they don't follow the, the intention.

So again, it comes, it comes down to discipline again.

Um, and that's, that's hard.

And also not a comfortable place to be, right?

Because, uh, discipline takes effort.

Uh, just doing your thing is a lot easier.

Exactly, and then people move on as well.

That's the thing.

If there's a, there's a churn, continuous churn of developers, which can happen

a lot of times, a lot of places.

Then there's disruption, and then disruption means things slow down.

Of course, when CH teams change and then pressure comes on to deliver and suddenly

ADRs, what ADRs, you know, so it's.

Yeah, it's that social element of coding, which is so important.

But not just the, not just the collaboration, but also the way

that we pass on information.

In fact, something you said about writing documentation or reading documentation.

I mean, that's the thing that, that I always do.

I always try and find documentation as soon as I start a job.

I'm trying to learn myself from the code how, how, what the architecture is, and.

How, how many places do I turn up and I say, well, where's, where's a picture

of the arch of, of an architecture view?

And no one can show me anything that's even up to date or

relevant updated in last year.

That's surely gotta be the starting point for anyone coming into the system.

But, uh, everyone learns differently.

That's, that's fine.

Yeah, so we talked about visual, uh, stuff earlier, right?

stuff visual, I think is always super important to have at least one visual

in your, in your project, right?

That you represent your architecture and, um, right, the high level

overview of what the system is supposed to be, how it's supposed to work,

just the high level mental model.

So everybody is, Able to talk about it, uh, and understand

it in, in a similar way.

if you have something like that and you make sure that you constantly

use it in the discussions that you have, you're gonna keep it up to date.

Because when you're having a discussion about it, you're

changing something, you're, you know, you have to change it, right?

So, uh, and the trick there is I think, to.

And at Luminus we have our Luminus way of working, uh, which sort of a document that

we try to help everyone here with to sort of have some principles and guidelines

to follow on how you do these things.

And we have a sectional documentation there, which says try to write the

minimal amount that you can, right, that you need, but that you are sure

that you can keep up to date over time.

Cuz uh, in a lot of cases I see people producing just tons

and tons of documentation.

But yeah, there's no way you're gonna keep that up to date.

So, Um, another approach I really like is taking, uh, like visualizations

out of the actual reality, which is the, the code, right?

Um, so nowadays there's more and more tooling that allows you to do that.

That's way more useful than having, something that you

have to maintain manually.

Well, indeed.

Yeah.

I think that's, that's important as well.

I was gonna ask, have you used C4 diagrams at all?

Yeah.

Yeah.

I'm, I'm, to be honest, I'm a big fan of, uh, of c4.

I really, uh, um, like that concept, um,

Do you find that, um, that people look at you funny though

because you're like, when I, cause I'm basically C4 makes complete sense to

me as well and the context, the, the top level box is the most important

part of any, anything for me there.

Um, I think it's the most warm part of anything.

I, I will just stick with the context for you to be honest.

I really want to go into components or anything even, but,

Don't agree.

Totally

agree.

But I get looked at weird now because I kind of got, I draw these

blobs and I've had people, actors and stuff, and I say, this is our system.

And people go, well, there's, where's the, where's the architecture?

Where's the interface here?

Where's the network?

Where's the whatever?

And I'm like, don't forget it.

Forget about that.

We don't need to worry about that.

We need to know the actors.

We need to have the systems.

And that's it.

You know, these blobs.

Um, and I kind of like, I'm kind of second guessing myself now because I go into

meetings and I present this and, they kind of like, they've already raised all these

questions at a detailed level and I'm like, I'll, I'll have a meeting with 'em.

I'll say, listen, that's not important.

All we need to understand is the interactions at this level, and

then we can dig in into the details later or maybe we don't need to.

That's the point.

Yeah, and I think like C4 does it pretty well, right?

And you have the system level and that, uh, the container level is

usually quite useful still as well.

But the focus there is on giving you the context of where your

system operates in, right?

All the things that are cited.

Um, and I think C4 does it on a, like more technical level

or you still see the actors.

So, uh, it forces you if you do it right to, uh, to put a

lot of details in there, right?

You, you, for every system and for every, every container there, you,

you describe as purpose, right?

You describe its relation to other pieces you describe the kind

of technology that it's using.

So it gives usually a lot of information already.

Um, at least when you come into a project, I think a lot of, I, I see

a lot of my colleagues also, they create these kind of diagrams when

they come into a project just to get an understanding and they enrich it, right?

They give it back to the project to make sure it, it stays there.

Actually had a talk with Simon Brown, last year, uh, at one of the

conferences where we Ran into each other.

And, um, so I was playing with the idea of, of wouldn't it be nice if

we can have to sort of always up to date documentation also on that level.

Right.

And, uh, so I had a discussion with him about that.

And the outcome that we came to is that well actually the real value

of that kind of high level diagram is not so much having an up-to

date version of it It is drawing it together with the people working on it.

Right.

And that act of drawing it.

Yeah.

You sort of bring up the knowledge from the group, right?

You get all the knowledge about how the system works together and

you create a shared mental model.

And, uh, I think a lot of collaborative techniques also

in the domain of design do that.

And a, uh, I think that's, that's the bigger value, just not just the image, but

the mental model that you create together.

Um, so to automate it wouldn't do that justice, right?

Because you wouldn't be able to have that collaboration going.

So, uh, um, yeah, I think, uh, that's also important to realize.

Some diagrams you just have to draw.

Uh, and that's fine.

Uh, you can't automate everything.

There's essentially a lot of value in not automating it.

Exactly.

It drives a conversation.

That's the whole point, I think.

Yeah.

Um, so apart from c4, cause C4 has some, is it the Structurized

tool or the framework as well, which allows you to, um, to model.

There's some, there's some more kind of, uh, loose, loosely coupled ones, I suppose

you could say, which allows you to just draw the diagrams without having to set

up relationships and stuff, which is cool.

Any other tools that you would recommend as well, or mo or models, um, that you

Les.

Yeah, so I think in this space, like giving context , about a system, what I

think is really useful to draw a context map like from DDD, which essentially is

like the high level context overview of, a system, but then more focused on the

communication patterns between systems and especially also between teams, right?

Cause uh, context maps are a lot about the organizational

structure that you're dealing with.

Um, and then you draw them.

From the point of view from the team, right?

And then looking outward, what are the, the other systems and teams that

we're, uh, that we're dealing with and how, what is our relationship there?

And, uh, just being aware of that.

Being aware of what relationship you have.

Like are you downstream?

Are you upstream?

Uh, are you going separate ways?

Like all these things are important to understand or if,

do we have a shared kernel?

These kind of things are important to understand cuz it gives you.

A mode of operating, uh, on that relationship.

And yeah, being aware of that is really important.

And I think in a lot of case people are not aware of it, right?

So, and that leaves them to maybe communicate or expect things that are

not to be expected of that relationship.

So creating these context maps, uh, is I think, very useful as well.

So I say, yeah, uh, a high level C4 diagram and a context map.

I think those were, would be the, the good ones to get a, a feel for, uh,

how, uh, well, when I, when I would onboard on a, on a team, it would be

lovely if we would have these things.

And then I think the other thing you really need to have is like a

business model canvas for the part of the, uh, the part that you're

working on to understand, okay, what is the business you're trying to do?

Why are we actually building the system?

So these kind of things just to, to give you an understanding on the, the

business domain that you're working in.

Don't see them being shared in a lot of places.

But yeah, I think it would be great if every project would have those.

Yeah, you'd hope so.

But yeah, again, I think the, the temptation is always for everybody to

prove their worth on any project and people who are kind of developer or either

your developers or your bas or whatever role you play, project managers, everyone

wants to show that they know stuff.

So they, they want to break out the tools, they wanna break out

the low level stuff and get diving on details and show activity.

Through busy work a lot of the time and this kind of helicopter view, context

view kind of stuff is, it's rare.

It's rare to see and it's, it's a shame I think because yeah, all the stuff that

we've talked about the, yeah, finding legacy, building legacy before even

you built anything, you know, comes through rushing ahead a lot of the

time rather than taking a bit of time, stepping back and just saying, okay,

what are we trying to achieve here?

And can we agree on that, at least through this collaborative process.

And then again, we don't want to get the impression cuz that

that's also an impression that a lot of people have from domain driven design.

That it means you start to do a lot of design upfront.

Uh, but actually that's, that's still not what you do.

You really try to do it it, or you actually do it small.

You do a bit of thinking there, but then you try to bring it into

practice and see if it works.

Because then you'll learn whether it's actually the case.

So, uh, uh, definitely a bit more thinking up ahead, but not too much

Awesome.

Um, brilliant.

Well, Nico, this has been brilliant.

I I'll share a few things I think with our listeners.

Um, you mentioned this thing, the arc uh, plugin, um, in the

our unity.

arc units.

Yeah.

So maybe you could share the link with me for that.

That'd be

yeah, sure will do.

it's abl that, that sounds really interesting.

I want, that's myself.

I'll share a couple of other links about various things including the,

the DD meetup and, and DD Europe.

That'd be great.

Yeah.

like to say thank you so much for joining me.

It's been really good fun.

Yeah, same here.

Thank you so much to Nico for joining me today.

I hope you enjoyed the episode as much as I did.

I will include in the show notes, links to Nico's speaking engagements in his

workshops, and please join me again next time on the next episode of Loving Legacy.