Master Software Architecture

The Journey from Tinkering with Atari to Mastering Software Architecture

Artur Skowroński: Hi, I'm Artur Skowroński, and it's my pleasure to welcome you to GOTO Book Club. I'm head of Java/Kotlin development in VirtusLab company, and curator of the Vived Newsletter and today, I will have the pleasure to talk with Maciej Jedrzejewski, who is the author of "Master Software Architecture: A Pragmatic Guide." So, Maciej, let's introduce yourself. You are the star here.

Maciej Jedrzejewski: Thanks, Artur. So, as you already probably have heard, my surname is quite hard to pronounce, so everyone knows me as MJ, and I'm always introducing myself as MJ. I come originally from Poland, but I moved to Switzerland several years ago. And nowadays I work as a fractional architect, consultant, advisor, auditor, and sometimes also mentor. I'm the author of "Master Software Architecture" book, and it's great to be here.

Artur Skowroński: You have a lot on your plate. I wanted to go back to the roots and ask you the question. Because I assume that there was a point in time when you just decided, "Okay, it's not time for the crayons anymore. It's time to start to have some fun with computers." What was your first machine?

Maciej Jedrzejewski: So, maybe how it all started. So, the first problems I solved that I remember were hardware-related. And to this day, I still remember the first Atari. It was Atari 65XE. And the game...

Artur Skowroński: Okay. I also started with Atari, so we have some common points here.

Maciej Jedrzejewski: That's great, that's great. I remember these games uploading from cassettes. The slightest rustle could cause the game not to load. So, we had, for example, such a method that we took air into our lungs and did not breath for a while because, you know, every little disturbance caused the game to not load. And this is something that I remember. And later, I think I fell in love with processors and overclocking them to their limits. And this is how I burned a lot of components to the ground, including motherboards.

Artur Skowroński: And in those times, components were pretty pricey. So, okay, it was probably an interesting way to learn.

Maciej Jedrzejewski: Yes, it was an interesting way to learn. However, it was already this time that you were able to buy some old equipment quite cheap. So, I remember that I was paying, like, probably 5 to 6 bucks for something really old. So, it wasn't that bad. But still it was bad at the time when I was a kid because I didn't have a lot of money. I loved it.

Artur Skowroński: So, you have a tinker in your heart, that's for sure.

Maciej Jedrzejewski: Yes, that's for sure. That's for sure. And then I think it was already the first adventure in programming. Quite late, because at the age of 17, of course, not counting some scripts that I was writing in PowerShell or Bash. And then I remember that I started in high school with C++. And this adventure lasted for about 5 years, also during my university time. And then I switched to C#. That was my partner for, yeah, seven/eight years.

Artur Skowroński:I'm coming from the JVM space, so a bit of a different cup of tea. However, probably that was quite a close journey. Okay. So you have been tinkering with the old equipment, with the CPUs, hardware, the C#. So, I have another question. Why architecture? What is interesting about that particular topic?

Maciej Jedrzejewski: Why architecture? Oh, man, where do I even start?

Artur Skowroński: Because you are probably interested as you wrote a book about it.

Maciej Jedrzejewski: Probably. It's like asking a kid why they love a toy store. Because there is just so much to explore, really. One of my problems is that I can't be fascinated with one topic for too long. So, domain-driven design is the exception here, but in general, I have problems with that. And that is, for example, I would not be able to focus only on API design for years, or on microservices. But architecture, in general, for me, it's like the ultimate playground. So, you can do so many different things.

The thing about it is that architecture is this beautiful holistic process that touches every part of software development. And it's not just about writing code or designing APIs, it's about seeing the big picture. And what really gets me excited here is how diverse it is. One day you are deep diving into the business domain, trying to understand the core of what you are building, and the next, you are crunching numbers, figuring out how to handle massive scale. Then you are thinking about deployment strategies, release processes, testing approaches. So, for me, it never gets boring.

And don't even get me started on infrastructure topics. I mean, I started as a programmer, but there is something magical about working with Terraform, playing in the cloud, setting up message brokers or orchestrating with Kubernetes.

What is still very important to remember here is that architecture is not set in stone. It evolves, it grows, it adapts. You can't just set it and just forget it. Yeah? This is not the way how it works. And at the end of the day, what really makes this software architecture fascinating is that it never stops teaching you. There is always something new to learn, a new problem to solve, a new technology to explore. It keeps you on your toes, challenges you to think differently, and rewards you with the satisfaction of seeing your ideas come to life in ways that impact thousands or even millions of users.

So, I know it was quite long, what I said, but as a summary, it's just the perfect blend of creativity, problem-solving, and continuous learning. It's the heart of software development. And honestly, I couldn't imagine doing anything else.

Recommended talk: Learning Systems Thinking • Diana Montalion & Charles Humble • GOTO 2024

Filling a Pragmatic Gap in Software Architecture

Artur Skowroński: Sounds interesting. You said you are learning new stuff all the time. We'll be back on this topic, on this particular topic, because it's pretty interesting. However, now, before we delve into architecture, we'll stay there probably for the next few hours, however, I imagine you will have a lot of stories to tell. Like we said, you wrote the book. So I would like to ask you about that book. Why did you decide to write? From my perspective, there's a lot of quite good books on the architectural topic on the market. Why did you decide, okay, you want to add something to the discussion? What was the trigger?

Maciej Jedrzejewski: Let me tell you a story here. I started as a software architect around 2016. So I didn't have an official title, but I started my design tasks, workshops with customers, gathering requirements, analyzing it, recognizing the environments around me and so on. And I attended countless conferences and meetups, was involved in mastermind groups and discussions. I learned a lot. I learned microservices, caching, data streaming, NoSQL, Kubernetes, Docker, cloud technologies, and many, many more.

And these concepts have helped other companies, like the big ones, and mine will benefit as well. Yeah? For sure. I still remember the excitement of discovering these technologies and knowing I had to apply everything I learned. But the problem is that, in the last eight years, I've made almost every mistake related to software architecture that you can think of. Whatever I heard, I applied. I easily justified it to myself because these were always described as silver bullet solutions and, of course, I wanted to follow best practices.

But the problem is that this contradicts pragmatism. And instead, it would be better to just look for solutions that would help solve your problems in your context, and support your team in achieving great results. So I am talking here about mixing concepts, trying various things, having fun with software architecture, and remembering that every architectural decision has trade-offs.

I lacked patterns in the beginning and support from experienced architects. I was a bit wandering in the dark, grasping at one thing or another. Over the years, I have had to learn everything myself. And I can't count the time I have lost. And this is why I decided to write this book, really. It's a practical guide where you will learn about all the important areas like business analysis, security, architectural patterns, deployment and 3D strategies, testing, trade-offs, because this is a very important part of software architecture, that every single decision has its trade-off.

Artur Skowroński: Everything is a trade-off. Everything. Like in life.

Maciej Jedrzejewski: Exactly. And I just want to show, in this book, I just want to show the reader the map of key areas in an easy-to-understand way. However, one very important thing, even though it's very practical, very pragmatic, you just have to set your own path on this map that I give you. Because each software architect has their unique ways of dealing with it.

Artur Skowroński: Okay. You mentioned the reader. And let me follow up on this topic because I wanted to ask you the question, who is the target audience? Because every book... I imagine. I've never been an author of a book. However, I imagine that if you have an idea, "Okay, I will write a book," the first question you need to ask is for whom? And what was the answer in your case?

Maciej Jedrzejewski: In general, all software engineers who are either interested in software architecture...and it doesn't matter if you are a junior or senior developer, or you just moved to a software architect path, or you just started a software architect but feel overwhelmed by the amount of information. It's more about giving you a book which connects the dots. This is something very important.

Because I think we hear a lot about separate concepts like, "Hey, here you have microservices. Hey, here, you have API's. Hey, authentication, authorization, some other security stuff." So now you need somehow to connect dots. And in this book, I show my way of thinking, my path, how I handle projects, how I handle product development. So I think even if you are a junior, you are a starter, you will be able to get a lot out of this.

Artur Skowroński: That was also my impression because when I have been reading it, I was thinking about the people in my team who are just thinking what to do after being the senior developer, spending most of the time on writing code. So what is the next step? And I think that would be a very nice book for them to read. I agree with your impression who is the reader. As a person who read it, I agree that you probably had a good hinge on that. Because such a book is pretty necessary for people. Architecture, like you mentioned, it's very broad topic, very complex with a lot of different issues. So having such a pragmatic guide that will show you, okay, how it looks in practice, not just in theory, it sounds like a good idea.

Maciej Jedrzejewski: I have already heard from one of my reviewers and one reader that, "Hey, this is the book that I haven't yet read," in the meaning of it is really different from other architecture books that are in the market. So I think this is this niche.

Artur Skowroński: It's good to have a niche.

The Journey of Self-Publishing

Artur Skowroński: Talking once again about the process, because that's also something that is interesting. ' If people market, because I imagine a lot of people, maybe not a lot, however, there will be people who are interested not only in the book, but also in the process, because they are thinking about doing something by themselves. Maybe they have some ideas, maybe they want to create published books themselves. And yours is quite...I don't want to say unique, because this is the trend I see for the last decade that is getting more and more popular. However, I want to understand why it is self-published. Because you published your book by yourself.

Maciej Jedrzejewski: Yes. We can say that I published it by myself because I just used this Leanpub platform. And Leanpub just gives you a platform to write, and that's it. All the rest you are responsible for. And there are two primary reasons for my decision. First, I wanted to write the book in my own style, like, free from the constraints of the publisher's guidelines. I value creative freedom and independence from third-party influence. This was the most important part.

But the second reason was the financial aspect. So when you self-publish through platforms like Leanpub, you typically earn 80% or more of the revenue per book. And this is a stark contrast to traditional publishing where the author's share is often reversed, receiving only about 20% and sometimes less per eBook. Yeah? Because here we are talking about eBooks. For books, it's usually way less. So these were two main reasons.

But, of course, then everything is on your shoulders. You have to prepare the content of the book. You need to edit it. You should or you could hire a copy editor. I hired a copy editor for my book just to look at the sentences, just to look at the content, how it is structured, and so on. So it helped me a lot. You have to prepare the book cover by yourself. So this is something that I also delegated to the external consultant or service provider. So a lot of things...

Artur Skowroński: So it was like a project. You have been a project manager for your own book.

Maciej Jedrzejewski: Yes, yes. With setting my own deadline. You know, this is... I talked with several authors who publish for traditional publishers and they say that they couldn't write self-published books because the problem is lack of pressure. So, like, you need to put a lot of pressure on yourself. And when you work for a publisher, the publisher puts this pressure on you. So this is something that is not that trivial.

Artur Skowroński:I will go sideways a bit. However, it's probably the biggest problem of all these online courses that if you are going... Because I still remember times when people discussed the future of education that we do not need those old university buildings because everything is online. We have multiple online courses. We can go to Stanford sitting in Kraków. However, it's probably not the case because people are people. And if you are not pushed by the professors, by the proper schedule, sometimes... It's easy to start the first course. However, you are not able to go through the whole curriculum. So I see with books it's quite a similar story.

Maciej Jedrzejewski: I see it similar. You need to stay consistent. This perseverance makes the entire difference. 

Artur Skowroński: Very interesting. Great to hear that. It's very interesting from my perspective, the process like that, that it's not just writing. It's just being able to push your own deadlines to find the proper people. Like I said, project management works for sure. So it's an interesting direction. 

The Pitfalls of Domain-Driven Design

Artur Skowroński: Now, I would like to cover not just the, I would say, process and medium itself, however, also the content, because you mentioned in the book, there's a lot of mentioning of the DDD, domain-driven design, for those who don't know the term. I assume everybody who listens to such a Book Club probably has heard about the term.

However, I would like to ask you maybe a bit harder question because, for me, I like DDD. I like the concept of DDD. However, I feel it didn't deliver on the promise. Because I remember I started to be interested in DDD 10 years ago. DDD itself, it's far, far older. However, in theory, it sounds like every piece are there and it should work for most of the project if we'll just follow the framework. "Follow the framework" is probably the bad word here. However, follow some set of rules. If we'll go by the book, okay, it should work.

Still, during my career, while some elements of the DDD are pretty useful and I love, for example, creating the context map, I like having some piece of the ubiquitous language. There were not many projects that truly went the DDD way to the whole process. Because my impression is that people are starting to use DDD as the one shot. So, okay, now is the group of architects who will define the ubiquitous language, and will define some architectural boundaries.

We create a whole set of documents that are suggested because there's some documents suggesting DDD as well. And then, unfortunately, after this first initial spark of creativity, spark of energy, people just start to do standard development without getting back to the original materials. And I do not understand why. Do you have any idea why it's like that? Or maybe I'm wrong and it's just in my bubble.

Maciej Jedrzejewski: No, no. I think you're right. So, in my opinion, there are two big issues, at least issues that I have noticed when it comes to domain-driven design and software architecture evolution. Let me break them for you. First, there is this tendency for folks to just jump straight into the tactical DDD stuff, you know, aggregate, entities, value objects, all that, and I mean already coding stuff.

But here is the thing, they often do this without really getting a grip on the problem they are trying to solve or the domain they are working in. It's like trying to build a house without understanding the land you are building on. And the second issue is about the strategic part of DDD. Sure, we start off strong. We plan our bounded contexts. We create a context map. We have this whole plan laid out. But here is where it gets tricky. We often forget to plan for follow-ups. And let's face it, software architecture isn't static. It changes because our businesses change. Think about it...

Artur Skowroński: Hopefully. The problem is with businesses that do not change what is necessary. And it also happens.

Maciej Jedrzejewski: Exactly. It happens. It happens. Think about it. In that first year of development, you start to see patterns emerge. You see how your bounded context evolves and changes. Some grow, some shrink. You might realize that some parts are communicating too often with each other, which could mean you've got the boundaries wrong. And there is a lot of flux in the beginning. The real problem comes when you don't keep an eye on its evolution. If you are not careful, if you don't nurture it, you run a high risk of your application turning into a big ball of mud. And, yeah, trust me, nobody wants that.

And what we really need is to make this a continuous process. We need to care about every single decision we make, no matter how small it seems. If we have to add features, we need to think how we want to integrate it into the current landscape of the system architecture. And this way, our architecture can evolve alongside our understanding of the domain and the business needs. So it's not a one-and-done deal. It's an ongoing journey. Let's call it a journey. It's like AI stuff.

Artur Skowroński: Okay. Now, we have it crossed on our checklist. You mentioned AI. We can carry on.

Maciej Jedrzejewski: I think I will be talking about it later maybe. So, yeah, that's the key takeaway. Treat your architecture like a living, breathing thing. Nurture it, guide its growth, and it will grow with you. Ignore it and, yeah, you might find yourself in a muddy situation. So that's very important to know. It's just an ongoing process. And it doesn't matter if we are talking just about DDD. It's about every single thing that comes with architecture, starting from infrastructure components and ending up on concepts like modeling.

Recommended talk:Accelerating Event-driven Architecture with Domain-driven Design • Brian Zambrano • GOTO 2023

Common Misconceptions in Software Architecture

Artur Skowroński: I will follow up on that because you are a consultant. You probably have seen a lot of projects. How to do that in practice? Because do you need a special process for that, special group of people, special role in the team, or maybe it's something that should be just the breadth of the daily work?

Maciej Jedrzejewski: Maybe first about this consulting and how did I get there, and then I will move smoothly to the second part. So, for me, consulting isn't just a job. It's kind of a passion, you know? There is nothing quite like the feeling of talking with customers, digging into their problems, and seeing their faces light up when you help them find a solution. It's incredibly rewarding, really. And don't get me wrong...

As I said, don't get me wrong. You can certainly solve problems in a regular job as well. But the thing is that, in a typical role, you are often confined to a specific set of problems within your domain. You might spend years working in the same area, which has its benefits, sure, but it can also limit your exposure to other domains, other projects. And as a consultant, you get to switch domains regularly, meet different people, experience various corporate cultures and work with teams of all shapes and sizes.

This keeps you on your toes, always learning, always adapting. And often, companies already have brilliant software developers. They are smart. They are talented. But sometimes they just lack experience in software architecture and fall into common traps. And this company, for example, does not have any budget to hire software architects because, yeah, let's be honest, software architects are usually quite expensive. And this is where I come in as this resource as a service, a consultant. 

Artur Skowroński: It's a support role. The role that you need, however, it's not having a direct impact on the delivered feature in the way that, okay, we have more developers, we will just deliver something with the customer quicker in the short term. It's paid off in the long term. So it's an investment.

Maciej Jedrzejewski: Yes, it's an investment.I described it in the book, that this is some kind of investment that is never seen. Because if you don't focus on software architecture, you will see a lot of problems probably in three, four, or five years with your maintenance costs. They will grow exponentially at some point. And it might even kill your business because your profit that you get from the application will be less than the maintenance costs that you need to cover.

Artur Skowroński: Or you are lacking flexibility and you are not able to compete. I understand that. And this is something that I've also seen a lot.

Maciej Jedrzejewski: Exactly. But you know, the funnest thing is that if you focus on this architecture over all these years, you evolve with it, then it's not visible. Non-technical people like business people, stakeholders, they just see, "Okay, there is some maintenance cost. This maintenance cost is cool. It's low." But no one sees that it's thanks to this focus on software architecture. So if there is no focus, then it is immediately visible. If there is focus...

Artur Skowroński: Business people see software architects only if there is a problem in software architecture. They don't care about it if everything is going smoothly.

Maciej Jedrzejewski: Exactly. It's quite funny because sometimes I offer these free consultations for companies. And this is, like, in 30 to...even 30 minutes to one hour, I can give them a direction to explore, you know? I might solve...maybe not solve their problem, but just point that, "Hey, look at this one." It might be a tool, a concept, or a short-term plan. They get this for free and I am completely okay with that.

There are times when such a company asks me to implement this tool. But I am honest with them. It will be much cheaper if someone from their team does it. Yeah? It makes no sense that I integrate this tool as a software architect because, yeah, this would be more expensive than in comparison if you leave it up to your team. But I love to work together with teams. I'm not the type of consultant that comes and says, "Hey, go in this direction or go in that direction," and that's it. No. I love to touch all these things and I love to dive into their problems. I love to dive into Kubernetes. I love to dive into modular monoliths, micro services and all this stuff. Yeah, this is how I try to stay on the edge of technology.

Artur Skowroński: Sure thing. As I said, once again, you've seen a lot and you have a flourishing concept and career. So I want to...because you mentioned one of the silver bullets that we are talking about, DDD. Have you seen any other that people think, "Okay, that will work for sure," because at each conference, people are saying, "Okay, that's something that will solve my problems," and in reality, it's far more messy.

Maciej Jedrzejewski: If only it were that simple, right?

Artur Skowroński: Yes.

Maciej Jedrzejewski: Well, in my experience, there are quite a few magical solutions that people often talk about. They rarely work as universal fixes. They are great for their context, but not a universal one. And I think the one that I've been seeing most since, I don't know, let's say 2016, are microservices. "We have a problem? Okay, microservices it." So, sure, microservices are great for certain scenarios, but turning every project into a distributed system is a recipe for unnecessary disaster. We don't think about all the problems that it brings.

You know, when you work with monolithic applications, you operate in a single process, of course, if you don't scale. And all the communication within this monolithic application is handled inside this process. There is no usage of the network. And with microservices, you already fall into this world of problems related to networks. You have high latency, you have network errors, you have network partitions where your net is divided into subnets and they can't connect with each other.

And UX, maybe you just use some message brokers. So, again, you need to send the event from...or send the message from one microservice to another. So this is something that we don't think about. Add to that, testing. So testing is very hard in distributed systems. And I mean, here, let's say this integration part.

Then after microservices, I would go with trendy languages. I have a feeling like we are currently doing something in Java or C#. And, yeah, it's not good enough. It's slow. So let's replace it with Rust or Go. Yeah? But switching to just another language probably won't automatically make your solution better. It won't solve your architecture problems.

Once, in the past, I had a situation where I had a job interview. It was several years ago. And a guy in the interview told me that, "Yeah, the application was really slow. So they now think about replacing React with Angular." But, hey, this is not where the problem lies. Yeah? The problem is probably somewhere else, incorrect boundaries, too big database tables, and so on, and not just the problem of using framework A or framework B or a library B. This is something to remember.

Another thing is, for sure, cache. Like, yeah, our reads are slow. Throw a cache on it. Like without further analysis, without first looking at indexes, about optimizing queries, maybe about partitioning and sharding. So, you know, using your database to its limits before you throw a cache on it. Because if you throw a cache on it, you have additional components and you have additional problems.

Recommended talk: Five Things Every Developer Should Know about Software Architecture • Simon Brown • GOTO 2020

Serverless, AI, and Emerging Trends in Software Architecture

Artur Skowroński: I've heard it multiple times, "We will go Serverless and we'll just pay if it will be necessary to have much more computing power of the throughput." Now, currently, I see that companies are much more restrictive with finance and probably that is good for software engineers. Maybe not for the software engineers, however, for software engineering for sure.

Maciej Jedrzejewski: It's good. It was like one month ago or one and a half months ago, there was a startup that used Serverless. I think it was from Vercel. So Serverless on Vercel. And then they got a lot of traction. It was some kind of application with sharing photos, I think, or drawing style. Yeah, I think photos. And then they received a bill after one month and it was $100,000. Yes, a lot. A lot. Because if you just put automatic scaling, then, hey, it's an almost infinite possibility. So you can generate a lot of costs.

The last one that I want to mention, because I think we are slowly running out of time, is the AI. This is treated today, fortunately, not by developers, but by the businesses, it is treated as the solution to all problems, you know? But don't get me wrong, it's powerful, but it's not going to magically fix poor system design or unclear requirements.

At least today, if you allow it to build your system, it will work great because, yeah, you can have a screenshot of what you want. You can put it to, let's say, Claude AI or ChatGPT, and it will probably create a perfect front end for what you presented. But this code will become a maintainable monster in two, three, four years. And we'll be again in this diagram where we show this exponential rise of costs of the maintenance. And this can kill your business.

Artur Skowroński: If I understand you, if I can quote, just paraphrase you, AI will help us deliver what we want. However, I want to challenge us to make something better.

Maciej Jedrzejewski: Today.

Artur Skowroński: Today.

Maciej Jedrzejewski: Because I'm not saying that it won't be like that in 10, 20, 30 years. I don't think it will be faster, but you never know. You never know. It's really powerful. But still, I think we should treat AI as a supporting tool rather than the solution to all of our problems.

Artur Skowroński: Okay. Apart from AI, what are the most interesting trends in software architecture right now from your perspective?

Maciej Jedrzejewski: That's a great question. I think that we all tend to live in our own bubbles in this industry. But from what I've been seeing at conferences, meetups, and in the latest articles, discussions, there are definitely some trends that seem to be gaining a lot of traction. And first, I would say it is platform engineering. It is really taking center stage. It's like we have collectively realized that we need to empower developers with better tools and platforms to build on.

We can talk about different platforms, starting from cloud platforms on which you build, ending up with some internal platforms that help you just to deliver your features faster. This is something that is very important. And I think it's really well explained in another book on Leanpub. This is called "Platform Strategy," and it's by Gregor Hohpe. So I recommend reading this book because he really explains what this platform engineering is from scratch.

Recommended talk: Platform Strategy • Gregor Hohpe & James Lewis • GOTO 2024

Recommended Books on Software Architecture and Related Trends

Artur Skowroński: Because you mentioned one of the books, "Platform Engineering." For sure. I'm 100% sure that platform engineering is a very interesting trend that everybody should be at least aware of. That is something very important currently and people are talking about it. So it's good to know about what it is and how it can help your business.

However, what's... Because you mentioned that there's some book that people of your book should read, and I assume that there's more of those. Can you recommend some titles? Because we are wrapping up. We probably will need to end in a few minutes. However, that's my last question because, like we mentioned, your book is perfect as a first book about software architecture. What's your perspective as a second editor? Apart from "Platform Engineering," because that's already mentioned.

Maciej Jedrzejewski: And this will be quite funny because another book that I will recommend is from the same author. I am a bit biased because this is one of my favorite authors of all time, but his books are really great. And I would say that after reading my book, you can go with "Software Architect Elevator." Probably you have heard about it. It's a good book.

Artur Skowroński: I've heard about it.

Maciej Jedrzejewski: You haven't heard about it?

Artur Skowroński: I've heard about it. I've heard about this book. I remember. It's also on Leanpub?

Maciej Jedrzejewski: No. I think it was published by O'Reilly, if I remember it correctly.But it's also by Gregor Hohpe And this book offers you just valuable insights into the role of software architect. It explains that you should just go from the bottom level to the upper level. So, like, from the engineering room to the stakeholders meetings and back and forth and back and forth. So you are the glue for the inter-application development.

Second book that I think is super relevant is "Designing Data-Intensive Applications" by Martin Kleppmann. It's like... It's one of my favorite books as well. I think it's not a coincidence that it's so well ranked in Goodreads in software engineering books. And from what I know, they have already started writing the second edition.

Artur Skowroński: I also have seen the announcement because I'm waiting to put it on my shelf because I want a physical copy. However, I'm waiting for the second edition. It will be delivered by the end of the next year, so I will wait a bit as far as I know. However, that's definitely one of the best books I have read.

Maciej Jedrzejewski: Yes. And if I remember correctly, because I don't remember if this was this book or not, but it got traction several years after publishing for the first time, you know? Nowadays, everyone knows it. But I think it was for one or even two years not well known in the industry. And that was a crazy thing because it's a fantastic book, really.

Artur Skowroński: It needed to have some build-up because people started...it probably had a lot of word of mouth. And that was the reason everybody started to talk about it. And probably today there is no list of the best books for software engineers without this one. That's definitely...every book probably needs to have some time to get the traction.

Maciej Jedrzejewski: I hope my book will join this list as well at some point. We'll see.

Artur Skowroński: Fingers crossed. I believe it. It's possible. It's a very good piece.

Maciej Jedrzejewski: Yeah, but coming back to the other books, I would say another book that is worth to read after mine is "Software Architecture: The Hard Parts." So this is a book which shows the process, how to get from the legacy application to refactoring it using different patterns using... I remember that it was all about the composition there, tactical forking for sure. And then you realize if you need to extract part of your monolith to microservices or not.

I think this is a great book and it's written like a story. So you read it from the perspective of a team that struggles with problems. So this is a nice one. And the last one, but I'm just reading it, so it's not that I have finished it already is "Architecture Modernization" by Nick Tune. It's the book from this year. And this is something that I can also recommend to all…

Recommended talk: Architecture Modernization • Nick Tune & Eduardo da Sliva • GOTO 2024

Artur Skowroński: I didn't hear about this one. Definitely need to put it on my list

Maciej Jedrzejewski: Yes, it's worth it. 

Artur Skowroński: Okay, so probably we are finally running out of time. It was a pleasure. I learned a lot. I hope the viewers will also learn a lot. And keep your fingers crossed that your book will also be recommended by close to everybody in the industry. Like I said, I believe that's possible because it's a very good piece. And I will definitely share it with all the people who are keen to go into the architecture stream of work because it's not always the work.

That's probably yet another topic that we could discuss. However, this topic will take multiple hours. That would probably be the amount of time necessary to discuss all the topics related to architecture. That's a very broad field. It was a pleasure. And like I said, keeping fingers crossed for your book and for the future titles, because I believe it's not the last one we are getting from you.

Maciej Jedrzejewski: Thank you. It was an honor to be a part of this interview. Regarding the next book, yes, probably I will take a little bit of break because it takes a lot of time and it's quite tiring...

Artur Skowroński: I imagine.

Maciej Jedrzejewski: ...to write all the things, edit it, and so on. So, we will see.

Artur Skowroński: And all that project managing with it connected.

Maciej Jedrzejewski: I never say no. We will see. We will see how it goes.

Artur Skowroński: Okay, thank you very much.

Maciej Jedrzejewski: Thank you.