Do you think that's the most effective way to create software
within a team? I think that's the only way,
being the architect, but also work with the teams and
generally be part of the teams and code with them.
They were just copy pasting all these folders and project
structures without actually understanding why they were
doing it. They end up being so dogmatic
about that that they lose the capability of optimizing or
simplifying that code base. I feel there will be a point of
time in the future and I don't have a clue how fast that future
is going to be that we don't care about the code anymore.
If you use open source code, it may eventually become your own
code that you have to maintain. It is almost like you give, but
you get so much back from it. Knowledge, experience, new
tools, new insights, feasibility of course, and that is very
valuable. Today I'm joined by Dennis DOMA,
Microsoft MVP, open source legend and Coding architect over
at Aviva Solutions. Last time we spoke was four
years ago. We talked about quality and
software engineering and a lot has changed, which is exactly
what we talk about. Strong conventions, battling
complexity and the impact of AI on open source.
So enjoy. You mentioned you would never do
conferences full time because you love your job too much.
Also because I Nah why would I do this full time?
There's no point. I still want to be able to do
things myself. I'm, I'd like to call myself a
hands on architect or coding architect.
And almost everything I talk about is based or fuelled by my
experiences. And if you stop coding, if you
actually stop building production systems and put them,
you know, put them in on the Internet and everything, you
lose that, that, that experience.
I mean, let's imagine I would have stopped coding myself for
the last three years, then I would have probably missed the
whole AI scene. And I really, I'm 52 now.
I've been doing this for almost 30 years.
I can't even imagine stopping this for some reason.
I've always been lucky where my job or my assignment is usually
a combination of being the architect, but also work with
the teams and generally be part of the teams and code with them.
Putting stuff in production. You learn so much from that and
being able to demonstrate that to developers like OK, if you
actually take a slightly different approach, this will
actually make your code more maintainable.
That is so valuable, but also running into the limitations or
learning new things about the framework or new techniques or a
new insight or a new paradigm or something like that.
I think that's extremely valuable.
And I usually only talk about my experience.
I don't talk about what's new in dot net 10 or something like
that. There's plenty of people that
can do that. I I like to talk about my
experiences, the pains and the successes that I've experienced
during my day job. Day job.
This responsibility of also being responsible for
architecture but still being hands on, do you think that's
the most effective way to create software within a team?
I think that's the only way. I can't imagine.
I mean, I do work with quite a lot of like, let's say
enterprise architects in the companies that I work with, but
they deal with the high level stuff they talk about.
They, they deal with policies and maybe information
architecture, but they don't actually have the experience
anymore to judge whether a certain solution will work
correctly or what's the consequence of using a
particular direction on the long term maintainability and
sustainability of a solution. So for me being an architect, I
mean, if if you're a software architect, I mean, there are
different types of architecture, there's a software architect.
The only way to be effective is to actually know what you're
doing, experiment, see how a particular solution that you
imagined is being used in practice.
Yeah. I mean, just fixing bugs in an
existing code base is already valuable, very valuable because
you learn a lot of stuff for that.
And I've, I've had, I had quite, I don't know, we're going down
all kinds of directions, but I had quite a lot of experiences
where I joined a client because I'm a consultant.
I work for a small consultancy firm, Afiva.
And you go into a team and you look at the code base and then
you see they're struggling with the code base.
They struggling to keep it maintainable, too much coupling,
not enough cohesion. Well, you know, all these terms
or principles and then you, you look at that code base from a
higher perspective and suddenly you realise like them, that
looks like an, an union architecture, clean
architecture. And then you discover that
apparently somebody in the past had a kind of vision, but the
current development team completely lost track of what
the architecture was about. Like what was the underlying
architectural style? They didn't even know it
anymore. They were just copy pasting all
these folders and the project structures without actually
understanding why they were doing it.
And they, they, they, they end up being so dogmatic about that,
that they lose, yeah, the capability of, of optimizing or
simplifying that code base because they're just copy
pasting a particular pattern. And I think if you're not
actually in that code base, you will not be able to detect,
detect that. And if you're an architect and
you're, you're a Greenfield architect where you, where you
get the time to build up something from scratch, you make
assumptions when you architect, you probably, you know, you know
about the functional non functionals, you talk to the
stakeholders, you try to come up with an architecture that makes
sense. But actually making that a
reality, implementing that. I, I don't believe you can write
it down in such a way that the development team just says, Oh
yeah, we know how to do that because they will make mistakes.
You make mistakes, you make assumptions.
You may actually, you may have thought like, OK, I need a
particular abstraction or I'm going to use, I don't know,
event sourcing or something I've done in the past or CQRS based
on those non functionals. And maybe also based on this,
this gut feeling that you built after 30 years.
And then you discover that either it's too complicated for
the team or it's not. It's not performant enough.
You have to make changes or the team is not capable of making
decisions on their own that they're not experienced enough
to understand when that pattern applies or when not.
That is something you need to experience on the job.
And then reiterate, you know, it's, it's really like agile
development. You look at it, you implement
it, you you reflect on it, you make changes and that's part of
the job. Yeah, I truly believe that
software engineering or creating software how it is or how it
used to be as well as how it will be in the future is all
about paddling or maintaining kind of this balance between
what you have and the complexity that you build up.
So if you lose a fundamental understanding of certain
decisions that have been made in the past and you're dogmatic
about certain decisions and you don't really understand, but you
keep doing it conventionally, you might build up a lot of
complexity. Or you should be actually
keeping that in mind and kind of battling it as you go.
Because time is the factor here and complexity is just to it can
be make or break for your software at some.
Point and and if you, if you detect that, if you acknowledge
the fact that you have unnecessary complexity, some,
some people actually call it accidental complexity because
everybody's trying to do their best, but they sometimes don't
realize they make, they, they introduce something that makes
the code base more complicated. And if you don't need that, you
need to continuously invest in that, try to remove it.
But then usually you end up in in this discussion like, OK, you
know, we have built this system, different modules.
This module has been has become too complicated, but it does
follow the same pattern. Should we then remove the
pattern and make this module simpler?
Yeah. But then this code base becomes
inconsistent. You know, that that is an all
sort of thing. And then some developers will
say or some experienced tech leads will say, yeah, but I
prefer the consistency. So let's keep that complexity
because for aspiring developers, it might be easy to understand.
I'm more the person that will say, no, no, we treat this
module as a boundary. And the consistency that we want
to keep applies only to this boundary, this module.
So we keep, we make this module simpler because I know that if
you make it simpler, it will also be much easier to maintain.
You know, a lot of developers are struggling like, OK, what
does, why do I need this abstraction?
Why do I, how do I unit test this?
What's the scope of the unit test?
And we talked about this, I think 4 years ago.
This is still the thing, you know, how do you apply DRY?
Do you actually duplicate code? I'm a person that will duplicate
a lot of code because it reduces coupling.
But I do that consciously. It's not like, OK, I duplicate
everything. Well, I never duplicate.
And that is the challenge that I see a lot of developers,
especially if they reach the, I don't know if I'm generalizing,
but between 10:15 years experience, they start to learn
the patterns, they start to appreciate them, but then they
start to over overzealously apply them and stick to that.
And and if you then say, Abbott, we don't need this abstraction.
Yeah, but this is this is open for extension, close for
modification. You know, this is a single
responsibility principle. Yeah, but you don't need this
abstraction. Yeah, but it's ready for the
future. You don't need this abstraction.
I've seen this so many times. And it's impossible to
experience them because those developers will then, you know,
wave the SOLID principles in your face like, you know.
Yeah. But dude, you don't need this
complexity right now. You know, do you actually need
to support different databases? No.
But we may have to do that in the future.
Yeah. But do you actually believe that
you can create an abstraction that has where the semantics
don't even change between different databases?
I don't know. But I've defined, you know, I've
defined this abstraction. I've decoupled my code from the
database. Yeah.
But I. Mean it would be easy if there's
like a playbook or a rule book, right?
We followed this. If we just follow this and we
keep following this, then everything is like really good.
It's. Called Sequel and every database
implements the exact same no of course.
Yeah, no, like it's, it's, I would love that.
I mean, no, I don't think I would love that because I think
that would make things boring as well.
We can use. AI then to implement it.
In fact, we can already do that, but.
Yeah. I mean, this is for me the, the
interesting part in those conversations about kind of
conventions versus being pragmatic versus, OK, what do we
do for the future or what do we do for now and how much is it
going to speed us up versus how much complexity is going to add
that we have to navigate. I've always really enjoyed those
conversations. And now with AI assisted
development tooling, I wonder if we're going to have
conversations in a different matter.
Because how we do things, I feel like is accelerating to a point
where it might be really good and we might not really have to
care about how things are done if it still is maintainable in
the end. I think I, yeah, realistically,
I feel there will be a point of time in the future and I don't
have a clue how how fast that future is going to be.
Is that we don't care about the code anymore.
I mean, I don't know if you ever watch Star Trek TV series or
anything like that, but they don't code.
They either tell the computer to do something or they, you know,
press some buttons and suddenly everything works differently.
Of course, that was based on the past.
They probably the original authors wouldn't even be able to
imagine what we can do today. But I, I'm approaching this
point pretty quickly. I have, last September, I think
I've build a new open source project, some kind of HTP
mocking libraryfor.net. And I started with like at a
client project. We had to do a lot of HTTP
marketing because we were doing unit testing and at the right
scale, I would say. And I was using some other
libraries and I didn't like them.
I started building abstractions on top of them to make them
easier to work with. I was missing features.
So at some point I thought like, OK, you know what?
I've been an open source developer for 15 years.
I can probably build something similar, maybe even better.
Arrogant. I don't know naive myself.
So I started collecting all these notes in GitHub in an
issue. I created the repo, it was
empty, almost empty. I used some kind of template
that I built myself and at some point the issue in GitHub
contained basically all the features that are needed, plus a
couple of examples like I I actually thought about what the
API should look like and just out of fun the curiosity, I
decided to assign that GitHub issue to GitHub copilot.
You can do that inside GitHub. Yeah, to my surprise, it
produced a beautiful open source project implementing basically
all the features that I needed using my own conventions because
I already had set up editor configs and Roslin analysis so
to define what my coding conventions are and it was
exactly what I needed. After that I took the code.
Oh, no, actually when the when git up created the pool request,
I started, you know, asking additional questions.
So like I was looking at some of the unit tests it created based
on my examples and I thought like, actually, you know, this,
there's some additional steps. I want you to remove this.
And oh, by the way, can you also create some assertion methods as
part of the library? So it's easier to say, OK, did
the mock actually send or was there actually a request to a
particular endpoint with a particular route and particular
body? And I thought about it and then
I thought like, OK, can you, maybe, you know, I have an open
source project called Fluid assertions.
There's now 2 versions. Version 7 is still open source
fully version A's is like a dual license.
And I wanted to support both. So I, I left a, a pull request
comment, like, can you actually create 2 sets of assertions, one
for seven and one of eight? And it did that.
And then I said, like, OK, can you actually split that up into
projects? So I can create 2 new cat
packages from it. It did it as well.
And I said, can you also update to read me with some examples?
And it was incredible what it did.
And that's the point when I thought, OK, now I have the,
the, the bulk of the implementation.
Now I'm going to continue myself.
And from that point on, I started to treat that code as
mine and started to evolve. But still, I sometimes use
Copilot in GitHub to add new features like I create an issue,
assign it to it, but sometimes I do it from my IDE.
So I I now have a mix of both. What's interesting is that I now
have codes in my library which doesn't entirely meet my
standards. Copilot tends to create pretty
long methods, especially if there's a lot of sequential
related to logic, and I've kind of accepted that because I
maintain it myself. I've accepted the fact that this
code will be there for a while until the point that I'm going
to touch that and I'm going to refactor it to make to make sure
it follows my standards. So I kind of embrace this.
So I have copilot that generates implementation.
I sometimes use copilot in GitHub to add new features.
Then I go back to writers my my preferred editor and there I use
Juni and Claude like a mix, mix and match to also make changes
for me and a lot of things I do myself.
I think this is quite interesting because I feel like
this also highlights then still the pragmatic side of things,
right? You could have said, OK, this
doesn't follow my standards, therefore I'm going to change
it. But the pragmatic thing is, if
it works, if all the tests a green basically, then in the end
it does what it needs to do and I don't really have to touch it,
right? This is more of a subjective
thing, or it's becoming more of a more of a subjective.
It is, it is. And of course, the code is not
bad. I mean, it does follow.
I've set up all kinds of conventions so it works and I'm
still experimenting, for example, with instructions files
and now we have skills. I haven't tried that.
It's to my list to try that as well.
Yeah, I I've read about it. I still haven't figured out how
would I use this with for example a jet brace Juni also
because I switch agents all the time.
Within writer you can you can choose what you want and then
you have 15 different LMS to choose from.
So it's. It's a lot.
It's everyday is like a surprise, like what will happen?
What was I saying? But I do review the tests.
So even if copilot or an AI generate some of the code,
including the test, I do review the test to make sure like OK,
do I understand the test? Do they make, do they make
sense? Do they actually test what I
expect? And I use that also to look at
the behaviour. So is the implementation
actually doing what I expected? Does the API look the way I want
it to be? And then I continue to go back
and forth. But whenever I these days,
whenever I don't know how we end on this discussion, but whenever
I feel like OK this is repetitive and I think Journey
can do better or cloud, then I'll let it do it.
OK, that's the. That's the rule.
That's, that's kind of how I do it now these days, even for the
projects like this morning, I even asked the, the, the, the AI
to generate some additional tests to make sure coverage was
complete. But then I went back and then
reviewed every test to make sure they did what they did or they
did what they're supposed to do. And also to, to actually to use
the same patterns that I liked. And now what I do is then the
first thing I ask them again to make some adjustments, but also
at the same time update the instructions file to make sure
the next time it will follow this more closely.
That's not a guarantee, but that's the whole way I work now,
yeah. Yeah, I, I have been in teams
where during refinement the team preference is to completely fill
in a solution direction in the task, in the ticket itself with
regards to what are we going to change, kind of where is it?
These are the conventions, these are the patterns making a lot of
things explicit and without AI assist development tooling.
I did not like this way of working, but the only thing you
would have to do is pick up the ticket, read what has to be
done, and then execute. And I feel like nowadays the
execution side of things, that's accelerating, so you don't have
to necessarily do all the execution yourself anymore.
Which brings an interesting question for me, because build
is accelerating. I see tools pop up out of the
ground like mushrooms, basically out of nothing, out of thin air.
And my assumption is that research and planning, figuring
out what problems you need to solve is going to become more
and more important. Build is going to accelerate so
we can build really fast. And then distribution and
adoption is going to be more and more important than it now is.
Because if you build a tool like that, like it's just a finger
snap, how are you going to get your users Or what problems does
it actually solve if they can also build a tool for themselves
like you did with a mocking library, and then solve their
own problems by themselves? Yeah, that is something I'm
wondering, like, is it still worthwhile building open source
projects or something like that? But in the end, yeah, not
everybody has that capability. I think we sometimes forget that
we live in a bubble. And especially if I look at
myself, I, I, I'm very lucky that I get to speak at, at
different conferences. And I'm part of an open source
community that, you know, a lot of people that are in the same
space, which are always working, are always trying to be at the
brink of technology, doing what they can to learn as much as
possible. And also use conferences to be
able to speak to other people. I mean, a lot of discussions are
happening, you know, during the, the speakers dinner and the
evenings where you sit with people that are very
knowledgeable in their fields and you learn a lot of that.
And sometimes you forget there's a lot of people, a lot of
developers in our profession that don't have that luxury or
don't even know how to get that knowledge.
They, they just need to get it from doing the work.
I mean, I've seen a lot of developers that are completely
stuck because they work at the company where there's nobody
that actually brings in that knowledge and they don't have
that, that, that passion or, or drive themselves to fetch
information. So what I'm trying to say is
that we're probably doing it not just for, for us like the people
in our little bubble, we're doing for the rest of the, the
people that are doing it. And for example, like Mockley, I
basically told like in my client projects, the teams like it,
they enjoy how to use it or they use it.
And now we just use the AI to say, OK, rewrite some of these
tests, replace all the old mockling stuff and replace with
Mockli, or create some tests for this Azure function that
interacts with, I don't know, some external surface and use
that library to implement it. And it will implement that
because it's still the whole goal that I always have is to
make my code as readable as possible.
And you probably know from the past, I really enjoy test driven
development, the unit testing. And one of the things that I'm
trying to do is make sure that my tests are as self-explanatory
as possible. They don't contain noise.
I have all kinds of experiences and principles that I follow to
make my make sure my test actually can be used as
documentation. So using libraries that will
make these things more explicit without really convoluted calls
with mocking where you build up Jason strings and stuff, which
is not always useful. That's basically drive.
So I'm basically doing it for myself now that I think about
it. I'm building these things for
myself. And then I think like, OK, let's
pull it out of there, put it out there and see if it's actually
pick picks up if people enjoy it.
I mean, I, I resonate with that. I used to take a lot of pride in
kind of how my tests are organised and how my tests are
structured, not just for me, but for my future self, for my
future colleagues. I try and add as much context
that I can in pull requests, in commit messages, individual and
atomic commits that makes sense and are coherent.
I spent extra effort on that. And I feel like nowadays when
you're looking at your your tests and the quality that you
put in your code base, that is kind of your safety net.
And if you black box the software that you create and the
safety net is your tests, then definitely you should spend
extra attention on that and make sure those are robust because
then you can trust whatever is behind it, whether it's created
by human, by you, not by you or by an agent.
In the end, it doesn't matter. So I feel like this is going to
be quite crucial to make sure that your tests make sense, you
know what to test and also how to test.
I feel like it's going to come more towards the forefront.
Some people are already front loading that testing part and
then just generating based on the tests and the
specifications. It's also a way of doing it.
Yeah, until the point where we really don't have to write that
code anymore. Like if you look at open spec.
Yeah, that's pretty amazing. What I've learned from a
colleague has been demonstrating that during an AI evening we had
is that it's really great for starting something up, but at
some point still you need to take that code and treat it as
yourself. Which by the way is how I treat
all AI generated code. But I'm pretty sure I mean like
what is it 2026 now? When was when became ChatGPT
popular? I even lost track like. 2-3 end
of 2023 ish I think. It's only two years ago, two
years. Ago end of 2020.
Three and just imagine where we're now it's quick.
It's, and I'm not sure if you talk to, I intended to talk
during hello stuff anger conference by Richard Campbell
from Doner rocks and he kind of told us that like the technology
for AI has kind of reached its potential and the, and the fact
no, not they didn't reach its potential.
It reached the roof. Like they can't really, they can
still optimize the GPT and the, the, the machine learning and
the, the generative AI technology, but there's no, they
really have to make some kind of paradigm shift to move it
further. That's his statement right now.
And you still see improvements, but it's not this big anymore.
It's a tooling around that tries to, you know, it becomes faster
and more powerful, But I don't actually understand how AI
works. Honestly, I have no clue.
I mean I tried to deep dive but then I was like am I doing this
out of curiosity? Out of interest, what problem am
I solving with this? Is just knowledge to have the
knowledge. I see the tools, I can
experiment. I love experimenting in personal
projects, but also if I can in production specifically.
I've had cases where I went fully AI assisted development
workflow and then all of a sudden my context got
compressed. And they always say context is
like milk, never let it compress.
And I, I know why because it compressed the context and it
was like, oh, we have changes, let's merge them and let's just
push them. And I was on the main branch and
I was actually experimenting. So that was not a good idea.
Yeah, we didn't have the safety net.
So I, I've, I've made my mistakes and I've, I have my
learnings, but that's mainly through doing.
I'm having a lot of fun though. Like I was in a role responsible
for product like you mentioned, I need to be hands on to have
things to talk about on this podcast.
And I had a lot of FOMO because things accelerated and I think
they're still accelerating. So yeah, if you're not in an
environment where you can experiment, where you can
actually figure out what works for you in this newer way of
working, it's going to be hard to kind of catch up at some
point. Yeah, kind of similar experience
I had like I think yesterday or the day before I was, I was
using I think clothes within writer to make some code
changes. And I also made some manual code
changes. And I I keep pushing them.
Like I use a couple of git aliases to quickly push
temporary commits to my brand so I don't lose anything.
So whenever I use AII, first commit my changes, push them so
I can roll back and I made some changes, continue to make some
changes. And at some point I was looking
at the actual production code. Well, not production code, but
the, the, the real code, not the tests.
And I was, I was like, Hey, this looks like my previous
implementation. What happened?
And apparently for some reason, Junie or I think it was Claude
made some changes and, and did some of my changes.
And I was like, am I now like I was, I was challenging myself or
doubting myself like did I make a mistake?
Did I excellently forget to push it?
And then I used my knowledge of a git and did a Git revlog.
I started to look at all the commits that were made and I
discovered that two commits before I use claw to make some
changes, pushed it without looking and it actually undid
some of my changes. So you really have to be careful
sometimes and using a branch, a feature branch and pull requests
really help, especially because you can go to git up or if
you're stuck on Azure DevOps and go back and see what you what
you force pushed all the time because I use a lot of force
pushing. And the other thing you said
about experimenting, I'm not the I'm, I don't like experimenting
in the sense that I just start doing something.
You could say I use my open source projects to experiment,
but I'm not going to build something and throw it away.
I don't like that. But I had a discussion or not a
discussion. Like I was talking with one of
my managers at Aviva and he was asking like, yeah, I get all
these questions that people want to use AI and do we want, don't
we want to standardise or something or make a decision
which one we use? And I kind of said like, don't
do that. Let people use whatever AI tool
they want because it changes all the time.
And there may be tools that we didn't know about and can be
very valuable. Let them experiment.
We just track, you know, who's using which and and regularly
chip check up like, OK, are you still using this tool?
Should we extend the license? Because it's not about the cost.
You will earn back that money in in minutes.
You know, I also had some clients like I think at that
time where I tried to decide should we use copilot?
Do we even want to do that? Yeah, but we have 300
developers. Yeah.
So 300 developers times $15.00 a month.
That sounds like a lot of money. If you, if you think like that,
it's $15.00 a month, you earn that back in 5 minutes and 10
fold because it will give you so much power.
But then it's the other side. I think we didn't talk about
that. There's also a lot of developers
junior, I would say aspiring developers, junior sounds so
negative. Inexperienced developers that
either are too inexperienced to, to.
I would say there's 22 versions of them.
You have the people that don't want to use AI because they're
afraid they lose the capability to learn themselves.
They kind of see that. I mean, if you experienced
enough, you've you, you went through that process, you build
the skills on how to find something using Google, but
they, they don't want to use AI because they want to force
themselves to do the investigation and the
experimenting themselves. They do want to make mistakes.
Go to Stack Overflow, although there's not much happening
there. Go to Google, read
documentation, try to interpret them themselves because they're
afraid if they don't, they lose these, these learning skills,
the cognitive skills. And I read somewhere that
there's actually that the current generation has less
cognitive skills than the previous generation because
they're so grown up with, with Chachi Petit and everything.
And you have like, relatively inexperienced developers that
are using AI everywhere they can, but they miss the skills or
the experience to judge whether what the AI generated actually
makes sense. And I've seen that.
I've seen developers creating a pool quest with some changes.
And I was looking at it and I thought, like, does that even
work? And he said, yeah, the test
work, but do you understand how it works?
No. So you used AI.
Yes, I did. So you don't actually know what
this code is doing. Well, I know that know what it
tries to do, but I don't understand what these lines of
code are doing. And that's the point where I
said, OK, dude, I really support that you use AI, but use it in a
way that I don't see it, you know, kind of saying like, like,
I don't care if you don't practice test driven development
really properly, but make sure that the code is actually
designed in a way that I would if I practice DDD because I, I,
I, I, I'm a big fan of that. As long as you you can use
whatever code you, whatever tools you want, whatever
practice you want, as long as the code is really the way we
want to have it, then we can maintain it.
I think this is very interesting because in my, at least if I
look at myself, my educational career was always OK, you go and
you do the research yourself, right?
Because if you ask me and I give you the answer, it's not going
to stick. Well, I did that and then I went
into kind of adulthood and in my first job and they said, well,
do the research and definitely do that.
But also if you're stuck and if you feel like you need a quicker
answer, we are here to be productive as a team.
So if I can give you the answer instead of you researching and
being on an island by yourself for a day, ask and I'll, I'll, I
will brainstorm. So I asked, I learned how to ask
and I think the answer stuck with me because the answers made
sense. And if I didn't understand, I
would ask again and I would go deeper with colleagues and with
my team specifically. I learned a lot through that
through just reflecting with people, bouncing off ideas,
genuinely being curious and being like, just can you explain
exactly XY and Z? And I feel like I can't revert
time. I can't change how I learned,
but if I were to have CHA GPT right now, also from a coding
perspective, if I have a specific language, if there are
conventions that I don't understand, I ask and I go
through line by line, not every single line because I feel like
some stuff it's fine. If I don't understand this bit,
it's going to be OK. In the end.
I feel like it makes sense, but it's because you already have a
mental model. I feel like you can do two
things right? You can be the engineer that
copy paste from stack overflow pushes it to production, it
works, it's OK. Same with CHA GPT, it generated,
it pushes, it's, it's OK. Or you can be the person that
leverages whatever you have now. And that curiosity kind of drive
you in doing AQ and a with yourself with an AI tool that
can actually explain and reason and go deep and be like what
these are the architecture conventions.
And this is actually where it, it doesn't follow these
standards. And then you can ask, I think
your colleagues or your team, does this make sense?
Or is it actually a conscious choice?
And as long as you have a curious mind, as long as you try
and maintain your critical thinking, I think you can speed
up very quickly. You can, I'm, I'm trying to
think like in the past. I, I sometimes had to, well, I
often worked with, again, aspiring developers and you
typically saw scale. You have people that asked every
question. They were asking questions all
the time. And you have people that were
afraid to ask questions. And I can also imagine that the
people who are very hesitant in bothering the team, even though
that's the whole point of the team, we'll probably go to chat
Chiapati instead of even asking. I'm not sure if that will
actually give you a good or bad result because I do it myself.
I tend to like, I think a year or two years ago, a year ago, I
think I was wondering between Azure Function Apps or Azure
Container Apps and if you go on the Internet and try to find the
answers, you typically would go to stacco flow because this is
where the descriptions happen. Maybe in Reddit these days.
Now I just ask Chetty Petty and it will give me a nice breakdown
between the options and the pros and cons and I can continue
asking like what is acceptable. Another example, like a couple
of weeks ago, we were were wondering like, OK, we need to
capture some guidelines on how fast our website should respond.
What is acceptable, what's not? In the past, I would Google.
Now, I just asked ChatGPT and say, hey, do you know any
industry except the standards for defining how fast the
website should respond? And it gives me a beautiful
answer. And it can even tell me like,
oh, you want some examples of websites that document this or,
or sometimes there's documentation that's not
properly. There's no, there's no industry
standard, but it has kind of, you know, yeah.
What I was trying to say is that ChatGPT or GPT or AI is capable
of interpreting different versions of the truth and try to
combine that in a certain way, which is a nice way because
sometimes you do want to hear different stories or different
perspectives of a problem and get the combined result.
And it's ridiculous. But I use it every day, many
times a day, even when I was trying to buy a new car.
Get feedback on what are common problems with that car or or you
know what is better or what what do people say about it, about
this particular type of car. I used everywhere now.
Yeah, I'd love to get your perspective on this because I
did AQ and a episode recently and someone said, OK, if you
were to be responsible for actually building up a person
that wants to be a software engineer, they start from
scratch, what would you focus on specifically with what you know
nowadays? That's a really good question.
Sorry. That's a really good.
I don't think I answered that in a good way because this is one
that can go quite in a lot of directions to be honest.
This happens like this particular situation happens a
lot because I have a couple of pretty young developers in my
team. In the end, I think it's still
the way it happened in the past. It's letting them fix box in an
existing code base, letting them pick up small improvements where
they touch a big chunk of the code base and learn about that
code base, let them ask questions.
And one of the things I do, and I've been doing this for many
years, when they create a pool request, I, I review it and I
use emojis in my poetry, not because I need to express my
emotions, but what I'm trying to do is I tried to emphasize how
they should interpret my, my code review comments.
So I use, for example, a pickaxe to say I'm, I'm nitpicking.
And especially in the beginning and with new, new joiners, I do
that more, I do that more extensively, even though I
shouldn't be nitpicking, but I, it's my way of saying, OK, this
is OK. This can be done better for
business reasons. And then I use different things.
I use thinking person to say, OK, you know what?
This is probably OK. There's different ways of doing
it. Let's discuss that.
And then I use that opportunity. They probably call me or we at
the office or we discussed that and I tried to explain them the
pros and cons of that solution and make them thinking about it,
make them think about it. The other things are sometimes I
use a camp campground icon, you know, to leave the campground
cleaner, which also is for them an opportunity to understand,
OK, so my code is OK, but there's, there's ways to make
that better. And I think that's, that's
already a learning exercise by itself.
And if they're stuck on a particular solution, sometimes
even though I know the answer, I ask them, look, no, maybe you
should ask Cha Chi Patee or or Juni or whatever AI you're using
to see what they come up, come up with and use that as a
discussion point. You know, they do that and we
have actually something to discuss about.
Interesting. Yeah.
Because especially if you talk about architecting the system,
what kind of abstraction do we need?
Why would we use the dependency inversion principle in this
solution to decouple something from each other?
That is not something an AI does for you.
That requires like a holistic view on what you're trying to
do. And I don't think an AI can do
that right now. This is actually the value.
And as long as we need to maintain the code, we need to
think about coupling A cohesion and that kind of things.
We have still to think about that.
Yeah, yeah. The thing you triggered me when
you said, OK, some people will ask ChatGPT instead of asking a
colleague. For me, there are a lot of
things that my opinion is of myself, I should know these
things and I just don't. And then I can ask a colleague,
right? I, I feel he's a bit
embarrassing and probably from the other side, it's not
embarrassing at all. This is really just this
imposter syndrome feeling. Or I ask and I use a tool to
kind of better figure out what is actually going on before I
ask a question because I will still want kind of human
feedback, a human in the loop in the end for my decision making
power. In essence, I feel like we have
a tool that can give us a lot of input with regards to what is
there and also how historically things have built.
Sometimes if you are in a project that is quite far along,
there is no single person that knows the context and the
history of the code base. But now you have a tool that can
actually facilitate that information, that distribution
of information to you and it can do it quite well, which is going
to be quite interesting for like modernizing software in essence.
But we are still, we still have to take ownership, we still have
to do the decision making and we still have to align on things as
a team, I would say. Yes, but the tool can help you
understand a complicated code base.
In fact, I use that also like especially when you have a lot
of micro service architecture, you try to figure out like how
does this information flow from one surface to the other?
You can do that yourself. Go through the abstractions.
Oh, I'm doing an HTP endpoint call here.
Where's the the handler on? Where's that HTPAPI on the other
side? I use AI for that, but
understanding the history and the reasons behind that, that is
the source control if you're lucky.
And that's also one of the reasons why I still are very
obnoxious about making sure that people create pull requests that
describe not just what it tries to do, but what is what's the
reason for that. And I still do that for commits,
for pull requests, for everything.
It should capture what you're trying to do, not how you did
it, because I can see that because that information is
lost. It's not it's not on a code bit.
Maybe by using comments you can I even do that and documenting
my code still properly 9 out of time.
I do that using AI, but it's really good.
So yeah. And by the way, that's funny
because I'm actually surprised. I use I use writer.
As I said, I often use AI or writer to generate description
of my pool of my commit because I still have a client that uses
Azure DevOps. I'm a big fan of it.
I'm not a fan of it that I said, but I I let the AI generate the
description and I'm often surprised that it somehow
figured out what I'm trying to do so just didn't explain what
files are changed or but it actually sees the value of that
and can and can write that in a functional way.
That's really solid. I don't even understand how it
does that, but I take that, that description and I put it in the
pull across description and sometimes tweak a little bit,
but it's better than Copilot, Git of Copilot, it's own summary
functionality because that's very technical.
But for some reason Claude and Junie can actually do that for
me. Maybe because it looks at the
history of the codebase. I don't know what we were
saying. Oh yeah.
So it's still valuable to make sure that your your git history
captures the essence the the the the purpose of what you're
doing. Yeah, absolutely.
I saw GitHub, they do this quite extensively.
They make business decision records, so not architectural
decision records because they want business outcomes.
It can be cost savings, it could be new revenue streams,
different or or magnitudes of scale, for example, that can
reach the business outcomes and they capture that in quite an
extensive documentation. If you already do AD Rs and if
you really work on historically capturing your context through
commits, through pull requests, through ticketing systems,
decision making records, I feel like you will be, I think
investing in the future because that context is quite useful for
humans and it's hard for a human to go through all the context,
But humans now have tools to actually go through all the
context. So the richer the context is,
the better we can make decisions and kind of understand
historically what has happened, which I think is really cool to
be honest. The companies that have invested
in that, they will be leaps and bounds ahead compared to the
companies that don't invest in that agree.
And, and, and you're preaching to the choir here because this
is exactly what I do with my clients quite often.
I try to convince them to adopt Confluence, Atlassian
Confluence, because it's a beautiful documentation
platform. And we use that to create
basically decision records, which is simple pages with which
demonstrate or show you some of the history behind decisions,
like the pros and cons. And for any non trivial
decision, we capture that because you make so many
decisions. And I've, I've been at certain
clients for a long time and what you, what happened at some
point, somebody new joins, maybe a new senior developer, maybe a
new architect, and they may challenge certain decisions that
I made in the past. And I make sure that I've
captured exactly what were the reasons at that time to adopt A
particular strategy. Also demonstrate even simple
tables, you know, with all the pros and cons and who were
involved in the decision and what other options did we reject
and for what reasons? I used why statements, why dash
statements, which is a nice way of doing that because I've, I've
had the pain of having to deal with that situation and I do it
everywhere. And most teams are like, why do
we need to capture that? And when you see after a year or
so, they started to see the failure like, oh crap, we
actually wrote that down. And in Confluence, you also have
like, AI, it's called Rovo. I think you can now just ask
like, hey, can you figure out why we decided to go for Azure
Container Apps, for example, as we'll find the decision page and
tell you, yeah, because of these reasons or, yeah, why did we use
private endpoints Azure instead of going through application API
management or something like that?
Those are decisions that you want to capture.
They're not even a code. They happen outside the code
base. That's maybe the flip side, but
I don't like writing a markdown in GitHub just for capturing
functional or technical decisions.
I think it's cumbersome. Have you ever seen those
practices of capturing decisions linked to a sunken cost where we
say, OK, we've made the trade-offs we chose for XY and Z
in this context, and that's why we're sticking to it rather than
looking at what is now and actually maybe pivoting or
shifting because of going through those motions of
actually capturing those decisions?
Yeah. In fact the example that I just
gave you about the new architect, I've seen that it
happened a couple of times, like I've been for one particular
client for a longer period of time, couple of years.
And like what happened a couple of times, management changes and
then management tend to talk to everybody, like trying to
understand the the department and they may talk to people that
are pretty young but influential, which didn't
actually understand some of the decisions I made in the past.
I started to talk to a manager and then a manager at some point
will come to me like, hey, I've heard that we're using this in
this architecture style, which the manager doesn't understand
at all, but it doesn't matter. And I heard it's causing a lot
of pain, you know, and then because I can go back and
demonstrate all that I can kind of circumfent somebody will
decide. Now we have to remove that
because we need to use a simple architecture.
Even though in all my I, I can honestly look at my heart and
say, like, I made that decision based on the situation at that
point of time with all the knowledge that I have, if the
situation has changed, this case, the situation didn't
change and there's no alternative, there's no reason
to change that. But I know that because I'm an
architect, I have the experience.
A manager doesn't have that. They just listen to, you know,
hearsay. So in that case has saved me a
couple of times. Yeah, Yeah.
I think that's super solid, one of the.
Last thoughts I wanted to share with you because I like your
perspective on this has to do with open source.
It was a few weeks back, I think I read this article about
Tailwind and the team that supports Tailwind, they had to
lay off 75% of their team. Now 75% sounds big, but it's
three out of four people, which is still a lot in essence, but
it's because their business model didn't add up anymore till
when it's there, it's free, it's open source and they have this
premium features where certain components and component
libraries that they've made, which are really cool, you can
pay for them and you get those out-of-the-box rather than
creating them yourself. Well, now with AI assisted
development tooling, you can basically say I want this
component that is in their premium functionality.
So you don't have to pay, but you still get the benefits
because everything is open source.
This is now a possibility, but it kind of brings at risk
certain options for making code open source.
Because if there's no business model in the end and you still
need to have a maintenance and a team behind it, it's kind of a
chicken and egg problem, right? If there's no money in it, then
people might lose the incentive to then make things open source,
Which is a shame because I, I really loved that part of this
community and kind of being a software engineer part of
things. Yeah, I definitely have thought
about it and talked. About it this last year, given
that I actually commercialized an open source project, which by
the way wasn't planned, it just happened was an opportunity.
I've always said, even way before I was doing that if you
use open source, it doesn't mean you get anything.
Well, how do I phrase this? There's no guarantee that that
code will last. And that's actually what
happened. A lot of people felt entitled or
feel entitled that if you use, if they use your open source
library, they feel like they kind of expect that this will be
maintained. Definitely like a service
almost. And what I often.
Do as part of an architecture role is write down, write down
guidelines for open source consumption.
And what I usually no what I always do is write down
something that states something in the matter of in the style
of. If you use open source, look at
the quality of that open source library, because if the person
or group of people behind that will no longer support it, you
have to support it. So just like AI code is your
code, if you use a, if you use open source code, it may
eventually become your own code that you have to maintain.
So there are things like, OK, is it just one man or one person
that maintains it, or is there an entire community behind that?
It's not. It doesn't mean that you can't
use it just means that you have to think about it.
Is it something that you use in your build pipeline or unit
tests? Because then it's easier, you
can be more lenient. Or is it something you use in
production? Because if it if it stops being
maintained, you have to do it yourself and it might be very
complicated. What's the quality of that code?
Does it have automatic tests? Does it have documentation?
Is the, does it use all kinds of code checking tools to make sure
that code is, is at the same level that you as a company or
team tries to uphold? And there's a bunch of more like
do they use a a proper branching strategy?
What's the code coverage? Do they proper read means?
Do they do release modes, release notes, stuff like that?
That kind of, it's not a single rule that says you can't use it,
but it's to make you really aware that it is in the end your
code. If you take that approach, it's
easier to to take something and and support it.
Because if, if, if the original developer decides to stop
maintaining it, yeah, then you fork the repostory and maintain
it yourself. You could have also decided to
say, OK, I'm going to write that code yourself.
I think in the end that is still much more expensive than take
something from the open source community.
We quite, quite a lot of people underestimate how much
complexity is behind that. I know that I've experienced
this first hand where people said like, oh, I don't, I don't
need these stupid fluent assertions.
I can build this in a couple of days yourself.
Sure. I've spent 15 years perfecting
it, you know, and even I I built four or five new open source
projects this year and there's a lot of energy.
It still takes me weeks of energy to improve things.
Even in fluent session eight, I was improving some kind of
reporting thing. When you compare collections.
I spent weeks on trying to find a good algorithm and
implementing in a way that actually makes it natural.
And I still use AI. People underestimate the amount
of work. I think Duanda is a good
example. Duanda has this AI.
Sorry, this authentication authorization library used to be
called Identity Server. A lot of people use that.
And when they became commercial, there was no discussion whether
the people want to pay for that because they realized how
complex something like that is. I think that kind of is an
answer to you. I think one of your points.
So in the end, use open source because it's probably cheaper
for you to start using it. And if it really dies, maintain
it yourself. And if that's too expensive,
then probably find something else.
But probably it was too complicated from the start and
doing it yourself would never have been feasible.
Now I lost track of my thoughts. No worries if people are
wondering, should I? Build something that is a
building block or I have something, Should I open source
it? You're a person that open source
a lot, why should they do that? What would you say to them?
It's fun. It is.
A nice way to demonstrate what you can.
It's super cool if you see other people appreciate that, you
know? Yeah.
And if you're lucky, people start adopting it and enjoy it.
And when that happens, and I had that with Mokli yesterday, the
first time one of my colleagues, new colleague, actually enjoyed
it so much, he thought like, OK, we found a bug.
You know what? I'm going to file a bug.
And I said, like, you're open to create a pull request and fix
it. It will automatically list you
as a contributor. And he said, yeah, I will do
that. And he created a pull request.
And that for me is always valuable.
And if I look at all the other open source projects, especially
through the assertions, I learned a lot from that.
There were so many improvements. People contributed at some
point, ideas of using tools or methods or something like that
that I didn't know about. I now have another library which
is called the.net Library Starter Kit, which I used to
combine everything I've learned about building packages into
likeyoucansay.net new and then it will generate an entire
solution. You can use it for open source,
for inner source, for GitHub, Azure DevOps capturing
everything I learned. And people contribute to that by
saying, hey, did you know about, I think it's called annotation
or not annotation attestation in GitHub.
I never heard about that. And you learn from that or
somebody else said, hey, maybe you can.
I have another library called Package Card, which is for
scanning your licences and open source packages.
And maybe you can add some additional statistics about like
the maintainability of an open source library.
And I thought like, hey, that's interesting.
I didn't even know about this service that I can use for that.
It is almost like you give, but you get so much back from it.
Knowledge, experience, new tools, new insights, visibility,
of course, and that is very valuable.
Yeah, I love that. Thank you so much for.
Coming on, Dennis, and sharing your perspective, this was a
blast. Yeah.
Last time was four years ago. Next time, hopefully it's not
four years I lost even I lost track already. 4 times.
Yeah. If you're still with us, let me.
Know in the comments section what you thought of this episode
and we'll see you in the next one.