# Strategic Legacy Modernization and AI Limits

**Podcast:** The InfoQ Podcast
**Published:** 2026-02-23

## Transcript

If you're the kind of senior engineer, architect, or technical leader who people look to for what's next, QCon London is probably on your radar.
Join us in London from March 16th to the 19th, where we go deep on the topics that matter, like the architectures you've always wondered about, engineering productivity and applying AI in the real world.
This isn't about trends for their own sake.
It's about getting practical insights from senior practitioners to help you make smarter calls on where to invest your time in tech.
With Softwanging Fast, QCon London is a conference that helps you lead the change.
Learn more at QCon London.com.
Welcome to the Architects Podcast, where we discuss what it means to be an architect and how architects actually do their job.
Today's guest is Chris Richardson, who is an architect who helps organizations modernize their architectures.
He's the author of P O J O S in Action, and the founder of the original CloudFoundry.com, an early Java pass for Amazon EC2.
Today, he is a recognized thought leader in microservices and speaks regularly at international conferences.
Chris is the creator of Microservices.io, a pattern language for microservices, and he's the author of the book Microservices Patterns.
He is the founder of Eventuate, an open source microservices collaboration platform.
It's great to have you here on the podcast.
And I'd like to start out by asking you: were you trained as an architect?
How did you become an architect?
It's not something decided one morning you woke up and said, Today I'm going to be an architect.
Gosh, I didn't know you'd open with such a tough question.
It's like, how did this happen?
But my first real job out after college, which was an incredibly long time ago.
I mean, actually, it's like 39 years ago, remember correctly.
I joined what you would call a startup.
I don't even know if that term was even used back then, right?
The goal of the startup was to build a Lisp system.
This was back in the mid-80s when AI was a hot technology.
I remember those days, thinking machines and all and sort of the primary programming language for AI back then was Lisp.
But Lisp primarily sort of ran on custom hardware, like symbolics machines and so on.
Because they actually provided hardware support for garbage collection.
Anyway, our mission was to build like a rich Lisp environment on standard Unix machines.
And me and some of the other folks, we were like fresh out of college.
And then there was going to be some senior academics, and they were going to work on the hard part of the system, the actual Lisp engine, and we were going to do the easy part and build the user experience.
But then they left.
So here we were, a bunch of newbies having to figure out how to build a state-of-the-art Lisp system.
And I guess that was sort of when I got it.
Technically as my second job after college, but the first one was just a continuation from what I did in college.
But it was like right at the beginning of my career here I am, forced into having to make big decisions around whoa, well I didn't even use the term back then, architecture.
And in this case, it was like, how do you build a state of the art Lisp system on mainstream hardware?
I think I might have had a fancy title, like chief software designer.
I can't even remember what it was called back then.
But I guess that's when I got just having to like make some important design decisions.
So it was sort of a trial by fire.
Yeah.
And that gave you the idea that you actually liked making these kinds of decisions, these trade-offs.
Yeah, it's kind of interesting.
I've just always wanted to work on interesting things and solve interesting problems.
I can emphasize with that because that's sort of what got me into architecture, too, because there were interesting problems to solve, and the architect was very often, especially when you're building a solution, that's very much where all the pieces come together.
From my point of view, anything that can't fit into a use case belongs to the architect.
Because you can't write a use case that says, make the system scalable, make the system secure.
Somebody has to be responsible for all those emergent properties.
Because if no one's responsible, they won't get done.
And that's how I see the role of the architect.
Yeah, I mean, it is funny, right?
There are various definitions ranging from the big decisions that are hard to change, right?
Later to I often talk about how the goal of architecture is to satisfy an application's non-functional requirements, like scalability, performance security, meh.
And of course, today, given the importance of fast flow, rapidly delivering software, the development time attributes like maintainability and testability and deployability become absolutely essential as well.
But then if you look at the research, it's like uh even the distinction between functional and non-functional requirements is a little blurred.
Yes.
I mean, you're sort of saying it, you know, flipping to be flipping it out.
There was a justice on the US Supreme Court when asked to describe what pornography was.
He said, I can't define it, but I know it when I see it.
And that's sort of like architecture.
You may be a little hard to define, but you know it when you see it.
Yeah.
It is all about making these impactful decisions.
That are non-functional requirements, don't fit in use cases, you know, those things that often fall through the cracks.
So one of the things that you have talked about is modernizing legacy systems.
We have all these legacy systems out there.
And there are two thoughts that come to mind when I think about this.
One is how do you understand those legacy systems and how do you evolve them?
And does artificial intelligence have any role in understanding a current system or giving you any clue on how to do this?
Well, looking at it from the context of microservices, right?
Which I've been interested in for a long time, adopting microservices usually means modernizing a legacy application, right?
In other words, migrating from a monolithic architecture to a microservice architecture.
And I sort of joke that enterprises have already written all of the software that they need, they just need to keep evolving it, right?
But I mean, obviously, greenfield development does happen as well.
And then it's like, well, why do you do that?
And one reason is the underlying technology platform that you're using is just absolutely archaic.
You know, when you have companies who've wrote software for hardware that doesn't exist and now it's running on an emulator on the cloud, there's sort of a whole bunch of technology governance things there.
And then more generally, just keeping your technology stacks current, right?
You know, I've remember working with clients where I think the core business system for like a really well-known company was written in some COBOL dialect that ran on, you know, back in the 60s.
And that's 60 years later, that was powering a business.
And they were in a kind of crisis mode because, like, I think the people who built that software and really understood it were retiring, right?
And then on top of that, I mean, obviously, applications need to evolve as their non-functional requirements change as well.
One example that comes to mind is, you know, in those days they did batch processing.
And now when you move to 24-hour day processing, you can't just adapt that software to the new world.
You have to actually take a fresh approach to it.
Yeah, I mean, it's sort of like we've gone from a world where all software just did this batch stuff in the background, right?
To oh, where we've got newfangled web technology, and that's how customers interact with things.
And then as you say, it's real time, it's streaming and all kinds of drivers like that.
Although I think batches alive and well, right?
One example that comes to mind is I remember there was a brokerage house whose name I will not mention because it would be well known.
Before there was 24-hour day trading, they had a batch system.
And you could say, at night, we'll run all the trades and clear all the trades.
That just won't work in the modern world.
Yeah.
Any other examples where the night is not long enough to process all of the data.
Yes.
I think that that's probably increasingly common.
Yes.
So modernization is clearly important.
I come at it from the perspective of microservices as an enabler of fast flow, rapid software delivery, right?
And given the volatile, uncertain, complex, ambiguous nature of the world and the need for businesses to be very nimble, architecture has to evolve to properly support fast flow, or concretely support DevOps as the development methodology and say team topologies as the organizational structure.
Which says to me that you have to evolve your architecture so that you can deliver small pieces at a time.
And you can deal with a very small piece and turn pieces off when you use feature flags.
You have to be able to piecemeal evolve your architecture.
And that's where microservices come into play.
It's interesting when you talk about evolution, right?
One of the really distinctive aspects of microservices is that each service can have its own technology stack.
So you can incrementally modernize the technology stack based on cost benefit analysis rather than having to do a big bang next generation technology refresh.
But you do have to get from that big ball of mud to that microservices architecture.
Yes, which is a very unpleasant experience, right?
Which can take years to actually do.
So how do you propose to do this?
You have a client who says we've got to modernize, we'd like to have fast flow.
We see that you know you understand team alignment, you have these patterns or the microservices architecture.
How do we get there?
I mean, fundamentally, it's much easier to describe than to actually do, right?
Um, but it's basically carving off pieces of the monolith and turning them into services, you know, which sounds straightforward, right?
But what that in reality means is identifying a module inside a monolith that would be a candidate to be a service, and then untangling it from the rest of the monolith so that it can be a service and interact in this sort of coarse grained way.
What happens when the data model makes it difficult to do that splitting apart?
Do you see that sometimes you have to look at the data model first and evolve that before you have the services?
Because it's very difficult to have a service that has a single source of truth if there's several services that are mucking around with the same data structures.
Yeah.
I would say the vast majority of the conversations end up on, well, what about the data?
Essentially, a module is well, a chunk of code, right?
And it's a slice of your database schema as well.
So it's just a subset of the database tables, and it might even be a subset of the columns of some of those tables.
And so when you extract it out, you're refactoring both the code and the data at the same time, which can be really, really complicated to do.
You know, enterprises tend to have like really complex schemas that are difficult for people to wrap their heads around, right?
So it's a really hard thing to do, but then it ends up just being absolutely necessary if you want to be able to re-architect so that you can accelerate software delivery.
I mean, there's this book, one of the black and red books in the sort of Martin Fowler Enterprise series, which I don't think really has got enough attention, is like refactoring databases.
I know the book.
I think it was Jess Humble who wrote that book.
Anyway, one of the tricks in the book is like you want to say to extract some columns out of a table.
Like one of the examples I use in my workshop is imagine in a food delivery application, order management and delivery management are basically intertwined, right?
So you look at an order table, it has columns that uh to do with order management, but then it also has columns that are related to delivery management.
And if you want to extract out the delivery service so that you can rapidly iterate on that and fine-tune the courier scheduling algorithm, you need to move the delivery-related columns into their own database, right?
But one kind of trick you can play is you could leave the columns in place as read-only replicas, and then when they change in the service, replicate them back so that those parts of the monolith that are reading those columns are completely unaware that the ownership is now in the service.
But presumably then that part that is reading them as read-only has to understand that there may be a latency or they may not have the absolute truth.
Yeah, that that is one obvious issue with this approach, right?
Is we're now in an eventually consistent scenario, right?
And you have to understand, you know, whether that eventual consistency do you have to assume that things will generally work, therefore you don't have to worry about things out, because then you have to get into an undo situation or a rollback situation, conceivably, if the truth turns out to be different than what the service made an assumption about.
Yeah.
I mean, there are messy transaction management data consistency issues.
Do you find that this situation is a temporary situation that it results from the process of developing the microservices and in the end they can go away?
Or is this just a fact of life or is it just depends?
Well, let's just say ultimately, right?
Like you extract module A into a service, and then module B is reading some replica of module A's data.
At some point in the future, module B is going to be moved into a service as well.
So it will be accessing module service A directly instead of this hack of a data replica.
So eventually the hope is that this sort of Kluge goes away when you have gotten a true microservices architecture.
Yeah.
Because you're going through the owner of the single source of truth.
Yeah.
So there's a bunch of hacks that in play that kind of grow and then hopefully shrink over time, right?
As you migrate things.
And when you're figuring out what to migrate out, you end up having to do some analysis to think about this sort of transactional data consistency.
And you want to migrate out chunks which are maybe larger than you want to in order to avoid inconsistent data that could create problems.
Do you find when you do this that reporting is another source of problem because when you do reports and you want to do joins on the data and you want to merge data, do you find that you can go through the services or you have to access the data directly?
Yeah.
I mean, I guess the sort of the reporting aspect is the other question, right?
It's like, oh, okay, we're going to split up monolithic system monolithic database into lots of little databases.
And then it's like, ah, what about reporting?
Because that requires a global view.
And I guess there's a couple of strategies, right?
One of which is I mean, maybe this is an order of starting with least desirable, right?
So that you could ETL out of each service's database.
But then that partially defeats the purpose of the microservice architecture, where you want to have loose design time coupling where things can change without having to coordinate between teams and accessing databases schemas directly is definitely a no-no, right?
So services could publish events, which hopefully fingers crossed encapsulates sort of a lot of the internals.
The data warehouse lake or whatever the trendy term is just subscribes to those events and gets updated.
The other approach that maybe is more in the philosophy of microservices is the data mesh concept, right?
Where services publish data products, and then you got all that mesh technology for reporting using said products, right?
Certainly there is a reason for pulling the read-only data out because you know you avoid lock contention.
If the reads and the writes are are happening at the same time with some degree of frequency, you don't want to necessarily be doing reports and updating the same database at the same time.
I guess I was sort of making the assumption that reporting across a bunch of services can't be done efficiently.
And so having that data in a centralized database is a requirement.
So strictly speaking, that is not always true.
Some kinds of reports could be done by collaboration through service APIs.
I mean, that is a possibility as well.
Is there anything else that you see is a critical issue that we haven't talked about in doing this kind of transformation or modernization?
As far as breaking apart the monolith is concerned, I feel like we've touched on the big issues.
One obvious thing to talk about would be well, what about just doing a big bang rewrite, which is what some organizations like to do.
And that is usually pretty much an anti-pattern, right?
I think it's incredibly risky.
You deliver no value until the rewrite is done, which is probably years in the future.
And then you also have not got any validation on your technical decisions until your application is deployed into production, it's in the hands of the users, you do not have any true validation that it is working correctly, right?
And the longer you prefer that, and the more that you build on unvalidated decisions, the greater the risk that you're building the wrong product.
Wrong thing.
Yes.
So essentially what you're saying is that one of the advantages of doing it this way is essentially at each point in time, you can look at what are my major risks in this gradual evolution of the system and choose to address them immediately as opposed to postponing them to some future point.
Yeah.
I mean, I think that is in a way an expression of the philosophy of fast flow, right?
Which is you are continually deploying changes into production and at the same time getting feedback on those changes, both from the production environment, which is where I made the right technical decisions, and also feedback from the users about how I implemented the right features, right?
And arguably the nature of the modern world and the complexity of the technologies that we're using require us to get fast feedback.
Otherwise, we really do risk building the wrong product the wrong way.
Yes.
The complexity of the modern world and the technologies makes me wonder, and I've seen this in several areas in the legal area, in the medical area, where people are saying there's so much information out there to master.
We need artificial intelligent assistance to help the lawyers, to help the doctors.
Do you see anything like this happening in the software world?
I guess we should talk about Gen AI.
Yes.
I swear though, I think that is an aside.
I mean, it's many things, but one of the things that is it is a mind virus, right?
Like software is eating the world.
Gen AI is eating our brains in more ways than one.
Right.
It's taking up so much attention.
And it is taking up a lot of my attention as well.
But it does sort of manifest itself in unhealthy obsessions with the technology.
Anyway, I think one of the challenges with a large code base is just understanding it.
You just don't want to go, oh, I'm going to throw AI at a problem.
Because you know, software is built by humans, and humans need to understand the software, right?
One thing I've done over the years is like, okay, we've got this legacy system, and no one understands it, right?
Or no one has a global view.
Each each team understands their particular part.
So one technique that I've used is this visible architecture workshop.
I did this once with this billion dollar project, and architects, like 20 architects from all over the world flew in and into a conference room, and they built a model of their architecture using Lego or duplo blocks, right?
String and stuff.
So it sounds kind of goofy, but people really enjoy architecting with string and blocks and so on and so forth.
So I still think that doing that kind of human activity is really important, right?
For creating a shared understanding.
Do you find that it's also useful to show management that this thing really is this complicated and it's really not that simple to take the next step?
Because I remember one time I was doing some sort of re-engineering project like this, and the manager thought, Oh, we have very simple data model.
So what I did is I sat down with the architects and had them put on the wall the entire data model, and it covered like three sides of this huge conference room.
And the CEO walked in and says, Wow, it really is that complicated.
Yeah.
I think it is useful to make that complexity visible because it's funny, right?
Like software just exists in a computer, and it's not like a building or an airplane or some other complex piece of machinery.
You literally do not see it in the same way.
And so, like, yeah, like this architecture thing we did, you know, the it was spread over three tables in a conference room with string going everywhere, right?
And it's like, oh, here's Postgres database, here's Cybase, you know.
It does bring it to life, it helps communicate the complexity to everyone and forms a basis for making decisions.
So yeah, that's really useful.
And then yeah, AI can help, right?
You can point Gen AI at a code base and ask it questions.
Earlier this month, I thought, okay, I'm gonna use Gen AI clawed code to generate some documentation, right?
It actually created roughly 70 pages of documentation for this architecture, diagrams with embedded mermaid plant UML and stuff.
But some of it was literally made up.
Like it just invented things, it invented the names of events and it invented functionality that had not been implemented.
And I had to tell it, please verify that every program language element that is in the documentation exists in the code, and then it goes, oh yeah, I invented a bunch of stuff.
You're right.
I mean, obviously, the code base was kind of small.
I mean, it was like maybe, let's just say of the order of 10,000 lines, but it was able to identify system operations that flowed across multiple services and create some sequence diagrams and documentation for each of those requests.
And it was kind of nice.
So let me construct a little thought experiment here.
Suppose we have a perfect world, whatever that means, and we have this AI architect, this piece of software that's called the AI architect.
What would it look like?
How would the architecture be done?
How would the A architect get the requirements, handle changes to the architecture?
Who would the design be proposed to?
An AI implementer or two people.
How would the incidents be said back to the A architect to improve the architecture?
How would information about improvements needed in scalability or security to be communicated?
Yeah, architect?
It seems that that it's really very complicated problem when you think about what architecture is and how an AI would handle it.
Yeah, it depends on who you're talking to, right?
Like based on reading LinkedIn over the past few months, that problem has already been solved.
Oh, I didn't know that.
You know, I just see a constant stream of posts announcing how amazing Gen AI is and how it solves all problems.
Maybe Gen I is generating those posts.
Probably is, right?
Yeah.
Like, you know, and the prompt says you're writing about Gen AI, use extreme hyperbole, and then they get massive number of engagements as well, you know, hundreds of reactions.
Just take a piece of that problem about requirements definition.
When I was teaching graduate school way back in the Stone Age, there was this idea that there'd be these requirements definition languages, which then could be taken and fed into these code generators that would generate this code.
These were very 1980s analysis is understanding ambiguity.
And computers are very bad at handling ambiguity, and even LLMs aren't any better in this regard.
How is the AI agent that's attempting to do architecture or attempting to understand requirements come to grips with ambiguity?
How would it ask questions to resolve ambiguity?
This this seems to be a problem to me that is extremely difficult to solve.
And I don't see anybody who's really addressed it.
Yeah, I mean, to be honest, I'm struggling to wrap my brain around the scenario you described because I feel like it's so far removed from my reality of what it's like to use Gen AI for development that I cannot imagine that scenario ever becoming practical.
So let me inject a little twist to this.
One of the things that proposed, and it's usually proposed in terms of creating human-level artificial intelligence, is that the AI needs a world model.
It's just not enough to have Gen AI.
You have to have a model of the world, whether it's common sense, relationships between objects.
Would it be possible to build sort of a world model of architecture that would help a AI architect in the future try to solve some of these problems?
Yeah, I mean, my sort of negative description of Gen AI is that it's a next token predictor that knows nothing and cannot reason.
It's so it's an illusion.
Which a lot of the time produces plausible answers, but fundamentally it really doesn't know anything.
LLMs to me are very strange compared to tooling that we normally use, where you know what it's gonna do.
And if you don't, it's because you haven't learned enough of the rule.
Whereas Gen AI, it's like I don't even know if there are any rules, right?
And you have to experiment and see what happens and come up with the right magic incantation to get this mysterious thing to achieve a reasonable result.
I have not found LMs capable of doing any kind of conceptual analysis or any kind of real abstraction about anything, and software is all about abstraction.
I use them to write code, and I think it makes me more productive.
And it probably does, but part of it is sometimes I think the studies have shown that perception of productivity is different from the reality of productivity, right?
And so in the realm of architecture, can it do any intellectual heavy lifting?
I guess I'm deeply skeptical, right?
I'm skeptical too because of this nature of my inability to get it to understand abstraction or conceptualization of anything.
As an architect, I have to understand a code base.
It can help with that, right?
And it can even help with a language that I don't even know, which could be very relevant if you're modernizing a legacy code base, right?
It can extract useful things, and also I use it to create proof of concepts, like POCs, right?
Or like little demos.
But then part of the problem is, as you mentioned earlier, how do you validate that what it's created is actually correct?
And as you say, you sometimes don't even find out what's correct until it actually goes into production.
I mean, it's funny.
I've been playing around with this simple proof of concept where I wanted a spring boot application to communicate with a Kafka broker using mutual TLS, right?
There's a bunch of containers, one of them is the certificate authority, and then spring boot application, Kafka container.
While back, I created like this proof of concept, and I'd asked it to create, I think, four, five proof of concepts.
And they're all different.
You know, each one is slightly different and works in a slightly different way.
And also, but also the Gen AI proudly said that, oh, this part, the inter-broker communication can't use SSL.
It just decided that that was not possible.
In all of the examples, but in reality, it is.
You just have to know the right Kafka incantation to set it up.
That's interesting.
Yeah.
It is interesting in the sense that, oh, you know, here I am, I'm trying to use it to learn something, create, you know, technology demo, but it's giving me misleading information.
Yes.
And fortunately, you knew enough to understand what was misleading.
Yeah.
Which did not necessarily have to be the case.
Yeah, and like the latest version, which I created last night, it interacted with the CA in a way that I think is insecure as well.
I think if I could summarize the discussion that we just had, the state of the art with AI and architecture at best.
It can perhaps help you understand a system if you're smart enough to ask it the right questions to have it validate itself.
But in terms of doing any kind of abstraction or any kind of conceptualization or understanding a big picture, it has a ways to go.
And we're nowhere near that right now.
Yeah, I mean, that is my feeling based on my experiences of using it.
But yeah, there might be someone listening to this podcast who vehemently disagrees.
Well, I can think of one person in particular.
Yeah, I probably think of the same one too.
But I do think that the behavior of Gen AI does depend on the particular context that you're operating in, right?
Or the particular problem that you're trying to solve.
Like, for instance, I don't know Golang very well.
I've used it to create some little Golang applications.
And it seems to excel at that.
No problem.
Of course, I have no way of judging the quality of the code.
I'm just judging by the fact that it builds a functional application for me.
Whereas with enterprise Java stuff, it's kind of like Java domain models, oh, it's great at whipping up things.
But then messing with some of the infrastructure stuff, I think it's all like what's in its training day, you know, what's it been trained on?
There's this unpredictability to it.
Yes.
And especially in a software world when we're constantly trying to do something that has never been done before.
Because if you think about it, that's what software development's all about.
Because if I'm an engineer, let's say a civil engineer, I can wind up building the same bridge over and over again for the rest of my career or some variation of the same bridge.
I think you probably offended civil engineers by saying that.
But but there's a lot of repetitive, well-based knowledge about how to build bridges.
And most bridges are not extensions of technology.
For example, when I was in graduate school, I took a course in nuclear engineering.
I got a massage to radical engineering.
And one course I took was in reactor design.
And on the final exam, there was a question of you have to build this cooling system for this reactor.
But the point was that you did not do it from first principles of physics.
You took the ASME standard and applied it to the particular cooling problem at hand.
But if I'm building a system, it's usually because no one has done this before.
And almost by definition, that's not something an LLM is good at because it's only good at what it's seeing.
I I would say two things.
I think there are two types of systems that get developed, right?
Some of them are just clones.
I think there is a tremendous amount of reinvention of the wheel, right?
Which is kind of unfortunate.
We're going to create the nth billing system again, right?
I think there's a large amount of that.
And it's possible within the one system, there's a lot of kind of wheel reinvention because you can't quite outsource it to SAS or a library or something.
But then there are parts of the system, the really valuable parts are the parts that are unique and special.
And hopefully they are so unique that LLMs cannot help with that, right?
There's not a lot of training data there.
I mean, it's funny.
Some of the examples that come to mind where I've had LLMs just sort of crash and burn recently would be like writing good quality tests for code that's for Kafka client code, right?
Completely lost.
Another example is I had an LLMs really useful to create a tool that can do code transformations more efficiently than an open rewrite recipe.
LLMs are insanely expensive, but you use it to write a tool that can then do the job for you.
But it missed a fundamental misconfiguration step with the open rewrite with the Gradle project that meant I just got continual null-pointer exceptions that had no clue how to figure it out.
So I think we've sort of gotten to some understanding of the limits of LLMs.
We've talked about modernizing legacy systems.
A more higher level concept, right?
Is I sort of feel like architecture in particular, but software development in general is all about making decisions.
So actually it's important for individuals, organizations to have high-quality decision-making processes, right?
I wrote about what I call deliberative design, which is like define the problem, right?
Which in itself is not always obvious, right?
And then actually figure out what good looks like.
How do you evaluate the quality of a solution?
And then it's good to brainstorm some solutions, evaluate them with respect to the various trade-offs, and then pick the best one or the least worst one, and then most likely document that decision like using you know architecture decision record.
And I feel like that decision making uh step actually happens at all levels of software development, right?
We're continually making decisions, and we need to be a bit more explicit in how we make those decisions.
Sort of a very basic point, but thinking things through is important.
It's very often the trade-off we make that we don't realize that we're trading off, is the one that will come to harm us in the end.
Yeah.
Was it a QCon?
There was an excellent keynote.
San Francisco, there was that excellent keynote about hidden decisions.
Yes.
There are decisions that you just make without thinking about them.
You know, and I guess maybe the prime example is if you're or you just sit down and figure out, well, how am I going to build this?
You should really have thought, should I build it or buy it, right?
Buy it, yes.
And that that's often the hidden decision.
But there's also a flip side of that hidden decision where some programmer, when they program an if statement, is actually going to make a trade-off that you didn't think of because essentially when they write that if statement, they're going to make that trade-off.
Yeah.
So this has been a very interesting conversation.
We've explored certain niches and corners of, I think, of architecture that people neglect or don't think about very carefully.
So I've I've found this very interesting.
This is the time where I like to ask my sort of architects questionnaire to all the architects to sort of get a more sort of human side to architecture.
What is your favorite part of being an architect?
Number one, it's I suppose, in a sense, I like solving problems in interesting domains.
I especially enjoy domains that actually have a real world physical aspect to them.
One of my clients this year was a logistics company.
And so I'm in the world of software, right?
But there's containers on container ships out there.
And that is so awesome.
I feel like I've been on this mission for decades now, figuring out better ways to build software and then sharing those ways with people and trying to help them build better software faster, basically.
What is your least favorite part of being an architect?
Maybe it's technology.
It's funny.
I'm sort of semi-theorid there in a sense that for a long time in terms of technology, I was like kind of, you could say, working in the spring Java space, right?
You step out of that, you go out, you're in the world of JavaScript frameworks, and it's like, oh my god, right.
Then I went down and I was in the world of infrastructure and Kubernetes and the Kubernetes ecosystem, and it's like, oh my god.
It's so complicated.
Maybe the fundamental issue is it's just badly documented, and navigating that world is shockingly difficult.
I mean, it's kind of fun.
Like, oh, it's like great provision infrastructure, right?
Like, oh, right, you know, writing a bunch of Terraform and Kubernetes and YAML to provision a Kubernetes cluster on EKS.
But oh my god, it's so complicated.
It's a miracle in anything ever works.
Yeah.
And I think maybe one of the reasons LLMs is so popular is because using modern technologies in a lot of cases is so complicated because they're not well documented that it's easier to have the LLM figure it out for you.
Assuming it tells the truth.
Yeah.
Is there anything creatively, spiritually or emotionally about architecture or being an architect?
Emotions.
I can neither confirm nor deny that I have them.
Okay.
Well, that was sad when Spock died at the end of Star Trek 2.
What turns you off about architecture or being an architect?
I don't know if anything really does.
I mean, I feel like dealing with infrastructure technologies is a frustration.
Okay.
So maybe do you have any favorite technologies?
Do I have favorites?
I mean, obviously, there's things that I've used for a long time, like Java, Spring, Spring Boot, AWS Cloud, and so on.
Are they favorites?
I guess they're favorites, but I I guess in a way I just sort of see everything in terms of just a bunch of trade-offs, right?
What's remarkable if you look back when I was doing software, like working on Lisp systems back in the mid-80s, right?
So I mean, basically it's 40 years ago, which is just shocking.
Hardware has advanced so much.
Like I remember we were excited when we got a Sun workstation with eight megabytes of memory.
And now I'm using my latest MacBook with 128 gig of memory.
Your phone has more memory than that.
Yeah.
It's like the computers are had L1 cache amounts of memory, right?
Yes.
But has software development evolved?
We're still over budget and we're still behind schedule.
Yeah.
I feel like the practice of software development, there's some sort of disciplines around like TDD and stuff like that.
But I feel like fundamentally it's humans just muddling through trying to make sense of stuff and writing some code, right?
And it, you know, the biggest development has not been in the evolution of programming languages.
I would say it's been open source libraries, so you do not have to build things from scratch.
It's been Google or at first it was Google, then Stack Overflow.
And then you could say LLMs as a way of looking things up.
But it's like the essence of software, it hasn't changed much in 40 years.
Programming languages, I mean, the mainstream of programming languages, right?
We went from C to Java, kind of a step back sideways to go Golang, but it's sort of, you know, like Common Lisp had, you know, rich functional object-oriented dynamic language with sophisticated IDEs back in the 80s, right?
What about architecture?
Do you love?
It's almost like the figuring out better ways to solve problems or better ways to build software, right?
So I kind of enjoy building software, right?
Solving problems, but I also like figuring out better ways to build that software.
What about architecture?
Do you hate?
Kubernetes YAML file.
Yes, yeah, I obviously think that was about it.
No, I mean that's sort of a slight, yeah.
I mean, it it's not like I hate anything per se, but I mean it's sort of obviously a source of frustration.
Yeah, I mean, actually, there's sort of this more maybe a better way of expressing some of this.
It's like we write all these like declarative configuration sort of based technologies, and then we kind of add func features in them to try and turn them into programming languages.
So there's you know, all these configuration languages basically are half-baked programming languages instead of a real programming language.
Yes, yes.
This argument has always gone back and forth between imperative and declarative programming.
There seems to be a tension between the two of them and two different schools of thought.
Yeah.
Well, I think about like Maven, real basic example, Maven XML versus Gradle DSL configuration language.
I would argue the Gradle approach is better.
Why would you argue that it's better?
I mean, because it is very declarative, yet when you need it, there's a full-grown programming language in there.
I don't know.
I'm just sort of throwing off random things right now, actually.
What profession, other than being an architect, would you like to attempt?
I guess there's one that I could admit to.
You know, to me, like human rights are really important.
And you know, I feel like we're living in a world where they're kind of neglected somewhat.
And for a long time I I've thought about in another life being a human rights lawyer would have been a nice thing to admit.
Yes.
Do you ever see yourself not being an architect anymore?
Well, I think more generally, right?
Like, could I imagine not doing software, right?
Regardless of whether you call it an architect or not.
Right.
And no, I can't, right?
You know, you'll have to pry the keyboard out of my cold dead answer.
I think that's how the expression goes.
Yes.
Yeah.
When a project is done, what do you like to hear from the clients or your team?
Answering that as a consultant, right?
The number one thing is I love to hear that I made a positive impact to their organization.
Um, I mean, that always gives me a sort of warm feeling.
And then more generally, like, you know, as an author, it's funny, right?
You can spend a lot of time just working away in isolation on things, and then you actually meet someone and they go, Oh, you made an impact on my career, right?
Positive impact.
And it's really heartwarming to hear that.
Yes.
I remember when I've written two books, and I remember one of them where someone come up and you say, Well, I use this technology and I learnt it from you.
Or we couldn't figure out how to do this, and your book explained to us how we could accomplish this.
That I find that very rewarding.
Hearing that is always just really nice.
Yes.
Well, thank you very much.
I have found this a very fascinating conversation.
We sort of touched a lot of different areas that I think are important for people.
But hopefully, their listeners will, you know, have some of their assumptions challenged and also some of the sort of the current hype.
You know, hear a countervailing point of view.
Yeah, I think we talked about it feels like a bunch of random things, but uh no, they weren't random.
There was a thread that goes through them.
And I think it's an important thread.
Yeah, so I I hope everyone who listened found it interesting or at least entertaining.
Well, thank you very much.
Yeah, thank you.