Everything is a Trade-Off - Software Architecture: The Hard Parts

Carter Morgan (00:00)

I'm always skeptical when I hear, like really in any context, but like software engineering in particular, like when I hear engineers telling stories where they are clearly the good guys and everyone else is just an idiot,

Hey there, this is Book Overflow, the podcast for software engineers by software engineers where every week we read one of the best technical books in the world in an effort to improve our craft. I am Carter Morgan. I'm joined here as always by my co-host, Nathan Toops. How are you doing, Nathan?

Nathan Toups (00:30)

Doing great, everybody.

Carter Morgan (00:32)

Well, make sure to like comment, subscribe wherever you're at, share the podcast on LinkedIn, your Slack channels, anything to help ⁓ extend our reach. Join our discord. You can see a link in the description or book time with us on Leland. If you want some one-on-one coaching time with Nathan and I, and thanks everyone for your patience. We did not expect to go dark last week. ⁓ that this was on me this time. ⁓ it's, it's, it's almost always on me. I don't say this time like, Nathan is usually doing this.

Nathan Toups (01:00)

It's okay, I'm banking my hours. I'm banking

my hours.

Carter Morgan (01:04)

No, no, we are. It's a, if you're been listening to book overflow, some of the podcast lore, I'm in middle of a big rewrite at work going very well. We're about 75 % done and we've migrated all of our most critical stuff. But last week was just a kind of the final full-time week. We've pivoted back to do some feature work now. And I was like, I just, ⁓ I do not have time to think about software architecture, the hard parts, ⁓ the book at least.

Nathan Toups (01:29)

because you're thinking about software architecture, the hard parts

at work.

Carter Morgan (01:32)

Exactly,

right. And so we appreciate all of your patience. Well, we are back this week with software architecture, the hard parts. And this is another one, Nathan, where like we read through chapter 17 of the audio book, but the audio book, yeah. Okay, okay.

Nathan Toups (01:51)

which actually finishes chapter 10 of the physical

book. So we're not ending mid-chapter. I don't think we've covered six all the way, so really today is gonna be six through 10, chapter six through 10 of the book, but in the audio book I think it was 10 through 17 or something.

Carter Morgan (02:03)

Yes.

Yeah, lots of great stuff here. ⁓ let's talk. let's give the book introduction, the author introduction. ⁓ we, did all the authors last week and there's four of them, so we're not going to quite do all that, but we've got Neil Ford, Mark Richards, Pramod Sadalage and Jamak Deghani. Now Neil Ford, Mark Richards and Pramod Sadalage are all friends of the podcast. We have interviewed all of them, so, make sure to check them out and also point out that,

We're not reading this book necessarily because like Mark messaged us and was like, Hey, you really should read this. we just, we love their work. And, ⁓ you know, I think these are some of the most talented authors out of everyone we've read. so, ⁓ we just kind of select this book naturally. ⁓ and it's been great. ⁓ the book introduction itself is software architecture. The hard part is tackles the difficult problems in distributed software or distributed architecture. The ones with no clear best practices where every choice is a trade-off.

Neil Ford, Mark Richards, Pramod Sattelage, and Jamal Khatigani walked through strategies for service granularity, managing workflows and orchestration, decoupling contracts between services, and handling data across distributed systems. They thread all of this through a fictional case study called the Sysop Squad, showing how these decisions play out in practice. We're two-thirds of the way through the book now. Nathan, give me your thoughts about what we've read so far.

Nathan Toups (03:30)

Yeah, so the book keeps a solid pace. I mean, it's really dense. Everything really is about trade-offs. I will say, I don't know, maybe I've gotten more used to listening to the audiobook. I listen to more of it hands-free this time than last time, except the second half of what we listened to, I had to sit there with the Kindle. Like, it starts getting so dense. And I'll tell you, the...

Carter Morgan (03:52)

Yeah.

Nathan Toups (03:56)

PDF that comes with the audio book is like 300 pages. It's just so many diagrams. they'll be like, diagram nine two does this. And you're like, if you're sitting with the diagrams in front of you, you're just kind of using your imagination. ⁓ And so yeah, again, I think this is a great book for deep diving. It was fun to explore these topics. And you definitely had a sort of like,

Carter Morgan (04:01)

Yeah.

Right.

Nathan Toups (04:25)

Phoenix project, you know, sort of feel to it with some of the extra stories that happened at the end of each chapter. So it was fun.

Carter Morgan (04:33)

Yeah, I'm still loving the stories. ⁓ think ⁓ stories in pretty much any medium are a great way to communicate and to educate. so this kind of ⁓ overarching story, the Sysop Squad is great. You know, am I going to praise the charming prose and dialogue of the story? Maybe not, right? You can tell it's a story written by some software engineers for educational purposes, but hey, it gets the job done.

I have not been able to sit down with the Kindle book too often. ⁓ Usually what I'll do is I will listen to the whole thing and then right before we record the podcast, I'll kind of flip through the Kindle book and just like refresh myself on specific concepts. ⁓ I think this is probably too dense. Definitely listen to it alone. But, you know,

we've said before, there are some books that you just don't lose anything with the audio book. Like I think you can just listen to radical candor and you're gonna be just fine. This one, I think the book, does add a lot of value. And I feel this way actually with everything we've read from Neil Ford and Mark Richards, which is just that like, there's a whole other world of like fortune 500.

legacy startup or not start legacy software problems out there. Cause it's, it's almost a little like, sometimes I think, I don't know if everyone has this problem, but I definitely have this problem where I kind of think like, okay, there's big tech, right? You know, it's like your thing companies, right? And then there's like your startups and your small businesses, right? But

And then there's just this whole other world. And that's what the CIS op squad is. It's the, it's the best by geek squad basically. Right. We're like, there's a ton of software architecture considerations to make when you're dealing with something that's like not necessarily sexy, but is huge and has grown over 10 years and, uh, services valuable parts of the business. So I always like the reminder that that world exists and it's a good model and

teacher for problems that ⁓ I haven't had to solve too much in my career just because I again I've either been in places that were kind of architected pretty well to begin with or are just too young to have those problems but ⁓ but I like it.

Nathan Toups (07:03)

Right.

I've dealt with lighter weight versions of it where, ⁓ well, I'm dealing with some of this now, even if it's not enterprise and I haven't been in the enterprise space either. You can definitely see that like ThoughtWorks folks, their target audience are, this is their bread and butter. They know their audience. They know that they're speaking to, you know, either some fresh ⁓ perspectives that have come into some large organization or.

Carter Morgan (07:19)

Yes, this is their bread and butter.

Nathan Toups (07:33)

ready to make some big changes, or it's folks that are like, you know what, I just need to make a change. We've been way too comfortable with this old process. It's not serving us well. ThoughtWorks kind of, these books kind of like unlock something there. And yeah, if you think about it, right, a lot of incredibly successful companies were early adopters in tech. And so this is why there are still mainframes running COBOL ⁓ with some critical banking infrastructure and things like this. Is it some...

Carter Morgan (07:58)

Right, right.

Nathan Toups (08:03)

you know, innovative thinker at the time, solved some problem at scale and, you know, modern version control didn't exist. There was no HTTP. was, you know, like all these things were kind of layered in on top. And how do you do this in a way that like helps you move towards a future you want to be in? you know, they never really talk about it here. They kind of dance around the team topologies thing, which is that a lot of this has to do with navigating really

convoluted organizations in which who controls what, who owns this. A lot of this stuff is like, how do I take this thing apart and make sure that there's proper owners and that we don't break things in the process? And if we go asynchronous, how do we do these things? I also loved this section of the book. We get into this other part. We're all the way up into, I think chapter like, I'm going to use the physical book. I think it's like around chapter eight of the physical book and about halfway through the audio book of what we were doing.

Carter Morgan (08:43)

Right, right.

Nathan Toups (09:03)

maybe 13 or 14 or something, we're taking things apart. Everything's focused on decomposition. ⁓ Here, OK, we have this thing, and there's too many things talking to a database, and here's how we break them out in a way that doesn't break the entire system. Here's the trade-offs. And then they're like, wait, and you can actually take this idea too far. And now that this thing isn't what you want at all, here's how you start putting things back together. I enjoy it. Again, I like this about Neil Ford books.

Carter Morgan (09:31)

Right.

Nathan Toups (09:33)

They really understand that everything is a trade-off argument. And I think that they're also addressing the fact that like, they might be walking into a consulting agreement where somebody came in and just bulldozed their way into microservices for everything. And it's so decoupled that nobody can reason about the stuff. And you kind of have this pendulum swing that has to go back and forth. And this book does a good job of saying, hey, you got into this sticky situation. Let's think through it. What's serving us well? What's not? And again, I liked that part of the book a

Carter Morgan (09:37)

Yes, yes.

Right, right.

Well, one thing I wanted to bring up with the book is the CISOPS squad. It's very funny. This is all, it's a little like the mosquitoes that are like frozen in amber from the dinosaur ages, because this book came out in like 2021, 2022. It's like right before LLMs and certainly before Claude code or the agentic coding harnesses. Right. And so.

Nathan Toups (10:22)

Mm-hmm.

Carter Morgan (10:33)

The whole SysOps squad is like the, this perfect little representation of like what was still today are like modern practices, but without these agentic coding harnesses. And so I've just been thinking at work, like, have you ever had a job where you, so like, again, pre-LLM where like you're, you're made for, oh, cause which is like crank out code.

every single day. Like you felt like you were limited by how fast you could type. Because I was thinking about this. I don't think I've ever had that job. The closest would have been my first junior job at a big entertainment company. But after that, I went to Feng and it was a lot more like operations. And so, you know, like I don't think I've ever quite had that. The closest thing would be what I have now. But obviously we have like

Nathan Toups (11:25)

Wait.

Carter Morgan (11:33)

What about you? Have you ever been had a job like that? Okay.

Nathan Toups (11:37)

I've never, I've never actually

had to, when we're, there was just like, I mean, I've definitely been in organizations in which we really did keep track of the point system. And I had a certain amount of tasks I should be getting done in a week, which was, you know, pretty well down to like keeping track of like the, you know, the burn down or whatever, if we're going to use, use this sort of agile methodology and we would keep track of those things.

Carter Morgan (11:49)

Bye.

Mm-hmm.

Nathan Toups (12:06)

they were loosely related to coding, I've always, I've been since I was CTO, then it's like, you know, it's all the way back in like 2015. So this is over 10 years now. I've been in a sort of mix of writing code as an IC and doing strategic work and strategic work just as lower code, right? ⁓ But I measured myself as far as impact. And so I never really, like if I could have a high impact with a low line count of code, that was a victory in my opinion, right?

Carter Morgan (12:15)

Yeah, yeah.

Right. Yes, yes.

Nathan Toups (12:36)

If I could solve a business problem in the least number of lines of code, I knew that that was reduction in potential tech ⁓ debt, maybe not directly, but it was a more elegant solution. But of course, I was also collaborating with folks who were writing a decent amount of code. A lot of times I was working with senior and staff level engineers who were deeply thinking about these critical systems and the stuff that they're building. But you're right.

Carter Morgan (12:39)

Yes.

right.

Nathan Toups (13:06)

It's interesting because I think the expectations have shifted. actually, I just had this conversation with another engineer recently, and I think this fits into this book really well, which was we were talking about is a guy who just went back into fractional consulting. He's like former CTO, was working at a consulting firm for a while. And he and I were talking about how we use sort of like vibe code or throwaway code.

Carter Morgan (13:24)

Okay.

Nathan Toups (13:35)

in our workflows. Like, I still am very conservative when it comes to like critical path code, where I really do want to understand every line. But I'm OK with things like certain types of test fixtures, or I just want to get the shape of something. I know I don't even care about the code if this is going to go into production. I really just want to be like, can I get this thing to do this thing that I'm thinking in my head? And I really don't care about the quality. I don't care about the edge cases. I don't care about how ugly it actually is.

Carter Morgan (13:40)

Right, right.

Nathan Toups (14:03)

And I'll let some agentic thing go off and come up with it and be like, is this possible? That's really the criteria. And I think that with the hard parts, this is really kind of interesting because instead of me getting in a debate with a coworker and being like, no, this is the better thing and that's the better thing, you could, with these little agentic tools, you could literally say, build this architecture where we've decoupled the database and we're using an event-based system and build this one where we're

Carter Morgan (14:08)

Right, right.

Nathan Toups (14:32)

having more traditional cues and a dead letter cue and give it these sort of workloads and let's see which one actually works. It's just toy examples. And I could go off and let those things cook, right, for half a day and come back with a real data and be like, hey, look, in these toy examples with what I think is actually a workload, like, this feels like it's ergonomic. Like, I like the way this was actually easier to handle the workloads like we expected.

Carter Morgan (14:59)

Right,

right.

Nathan Toups (15:00)

And that's just not something that was not that would have been a two week, you know, research and development cycle that was just not it was cost prohibitive to the business. was cost prohibitive to myself. Am I going down a wild goose chase? And I think this is where, yes, the hard parts are still the hard parts. Yes, you still have to understand tradeoffs like everything that's in this book is still applicable. But how quickly I can make an experiment and how in the expectations of the fact that I can make these experiments has shifted. I think that

Carter Morgan (15:03)

Yes, yeah.

All right.

Nathan Toups (15:29)

That's part of this.

Carter Morgan (15:31)

Yeah, that makes a lot of sense to me. And I've been thinking about like the podcast from a meta perspective lately, just, you know, in a large language model world where all of a sudden, like, it's spooky that they can generate code, right? There's a lot of, like you said, like, how much of it do you want in the critical path? How much do you like, how much do you need to actually change it? But I just remember the first time I saw it, like actually generate working code. I'm like,

but the machine needs the code. What do you mean the machine makes the code? This is insane. And so with the podcast, just, know, like sometimes my crisis of confidence, I'll be like, is this all a waste? I study the wrong things? Do have a master's degree in the wrong field? And the more and more I kind of at work, I'm like, I don't think so. I'm like, I think every book we've read, I don't regret any book we've read. In fact, I feel like they've all become more valuable in this day and age from like a, architecture pattern setting.

Nathan Toups (16:03)

Right? Right.

I do too, and I don't think it's a cope. actually, like, the more I've also spent, yes, it's true, true. So if you're also a fellow coper, welcome to the podcast. The thing that I've seen here is that complexity is an exponential. And you will screech to a halt if your foundations are poor. And I think we've all, yes, exactly, and this is just,

Carter Morgan (16:30)

No, I really don't. That's what everyone who's coping says.

Yeah.

Mm-hmm.

I am experiencing this firsthand at work. Yeah.

Nathan Toups (16:57)

I

think, and if we can get down to like, we can get real philosophical and talk about, you know, entropy and that like, you know, this is the law of thermodynamics and physics, right? It's just like, if you have to put energy into the system to keep things simple, if you don't, everything goes to a state of chaos. And that's just like the way the universe functions. It just happens that we're these entropy machines, like life is low entropy systems.

Carter Morgan (17:13)

Yes. Yes.

Right, right.

Yeah, yeah.

Nathan Toups (17:23)

where high entropy is the stuff, it's complete chaos, it looks like randomness. And to separate low entropy from high entropy takes energy, it takes an external energy source. And so everything falls apart. Like I just got an oil change from my car and the tires rotated preventatively because if I ignore those things, my car's gonna fall apart, right? I think the same is doubly true for large language model work is that if you just dial it in, ⁓

Carter Morgan (17:41)

Right, right.

Nathan Toups (17:49)

I think we're in an amazing time where prototype quality code is super easy to generate. And you can kind of play with an idea. But the transition from prototype hackathon level code to something that you can reliably make into a business, or you can rely on and grow and evolve, is a huge gap, right? And I think this is part of large-signature models in general. We're actually, as an industry, pretty bad at it.

Carter Morgan (17:53)

Yeah.

Nathan Toups (18:16)

Right, so if all the data and the training, like probably the folks that are the best at it don't have open source software, right? We don't have the ability to scrape Google or Meta's like entire internal code base. And I'm not even saying that those are perfect. I'm sure that there's warts and all in there, but probably some of the better examples of like building evolutionary architectures and some of the like really cool things are things that are not trained. And so what do we see? Is it open source?

Carter Morgan (18:17)

Yeah.

Yes, yeah.

Right, right.

Nathan Toups (18:43)

We see tutorials online. We see any of the code bases that are on GitHub. And so the large language model is going to do about as good as the best examples that are there. And they're not that great. like, which, again, maybe this will change in the future. Maybe, you know, large language models will use principle-based approaches and have better training and, you know, have ways of verifying things. I don't...

Carter Morgan (18:55)

Yeah.

Nathan Toups (19:11)

The expectations have fundamentally shifted. All of my client work that I'm doing now, right? And the cool part is I was kind of going from like underemployed to like, I'm super busy in the last three months. And every one of them has a very high expectation that I'm using agentic tools to help what I'm doing. That maximizes the value that I'm providing. But I'm also supposed to be a sober voice about what's not going to work or what's like.

Carter Morgan (19:29)

right.

Nathan Toups (19:39)

why they've painted themselves into a corner or why they're having problems. This gets down to fundamentals of software architecture. This gets down to me being good at the hard parts. This gets like, that's why it's agentic tools plus me being like, yeah, all this stuff's broken. Or like, you can't do it this way, right? ⁓ That's what makes me valuable. And so I actually feel very secure in that place right now.

Carter Morgan (20:03)

Yeah,

I feel that way too. I think we're all moving up the abstraction stack like Carl Brown has told us. And I think, you know, this is, it's why I've really enjoyed reading all these books. I actually have found just by reading books like software architecture, the hard parts, like I just find that my instincts are getting stronger, right? Like kind of when I explore a new idea, I can suss out a little bit, like, I think this is a good path or I think this is a bad path.

And especially in a world where your velocity can be so much faster, having those strong instincts and fundamentals are really, really important. But yeah, it's just so interesting. Like you're talking about like prototype quality. Like we had that this week where we, so we haven't built anything for the business in six weeks. So we just migrated, you know, rewriting the code base. And so we switched like 50 50 feature work. so

We, and we even switched that at work where we used to have like teams like three or four, and now we're down to teams of two. We're like, you know, let's try it with two people and, and cover more surface area and, use Claude more. See what that looks like. So we're experimenting. We're going to see what happens. So just me and my, my, my junior engineer, my buddy, and he's, and so we Leland is, you know, that's where I work is hoping to build some more kind like social media feeds.

or like social media features right on the platform. And so ⁓ what design handed us this time was not a Figma. They handed us a React app. And so isn't that neat? Just like a vibe coded React app. And so I told my ⁓ partner, I was like, hey, I'm like, let's just stick this in the app. I said, let's stick this, let's put it in like a siloed directory and let's feature flag it.

So it's only available to the company. Anyone else who visits this page will just get a 404, right? And I'm like, and then let's just like, we've been busy for six weeks and people are really excited about this. Like today, let's just launch it today to the company, right? And so like, yeah, it's this VibeCode React app. It lives on our website, just at a feature flag route. Our CEO went nuts. And like, I really like our CEO. He's a smart guy. He's like, I can't believe how fast this was. And so, but what's been really cool about it is that

As I've been playing with it, we built some basic backend functionality to make stuff persist and all that. As I've been playing with it, you're like, oh yeah, this is a prototype. There's so much that's kind of janky about it. But it's been really, really cool because the moment we got it on the website, all of a sudden it became real to the rest of the company. And we've had people from the rest of the company coming to us and being like, hey, do you think we could build this? Or I think my section of the business would really benefit if it could do this thing, right?

Nathan Toups (22:35)

Yeah.

Carter Morgan (22:56)

I think making it real was a really cool thing. But I think it's kind of like, we've been using Claude a lot during the rewrite and I felt comfortable doing it because we have just used it to generate enough code so far with, we have some good skills rigged up ⁓ and it had done a good job for the first 20 or 30 iterations. And so we're like, okay, I think this is good. It's writing integration tests and we're validating all of that. ⁓

And then the other big thing that really helps is that because the API contract is already defined from the front end and because the functionality does exist in a Java graph QR representation, quad isn't really making things up entirely. saying I need to create code that fulfills the contract already defined and that is copying functionality from something that already exists. And so it's very constrained and reined in, but sometimes it just generates so much code for us. I'm like, geez, Lily is like, does my job exist anymore?

Nathan Toups (23:43)

Right.

Carter Morgan (23:54)

Right? But it's all, but it's, it's just different because you're like, well, yeah, like it would have taken way more time to generate all of this code or it would have taken way more time to make this react prototype app. But we never would have done it. Like the workflows are just fundamentally different these days. And I think that's what's interesting is like the workflows are different, but the fundamentals are still the same. I don't think in anything that's come along in the LLM world that, uh,

Nathan Toups (23:55)

Great.

Yeah.

Carter Morgan (24:24)

the fundamentals of building good software have changed. And this is very, basically a very long prelude with this book, Soft Rock, the Hard Parts, is despite the fact that it's kind of like released right before LLMs really take off, and so it's kind of this frozen in amber moment, you would read this book and maybe expect a lot of it to be just be kind of totally outdated in this new paradigm, but I don't think it is. I don't think anything I have read here

Nathan Toups (24:53)

Right. No, and this actually, I need to write this down because I've been thinking about this a bit. Do you remember in graduate algorithms, we had to deal with this thing called, it was in linear programming section, and you had to define whether something was, so I'll bring a little trigger warning, but so you would have this X and Y axis, and some of the problems you had to decide, is this bounded or not, is this feasible?

Carter Morgan (24:54)

is outdated.

That was my worst exam. It's the first one and you get wrecked.

Nathan Toups (25:22)

is what it was. And so you'd have these lines that overlapped and then all you had to do is figure out how to get to one of the corners and one of the corners in this bounded region was the maximally correct solution, right? So we don't have to understand the details. Part of the problem was, is this bounded? And can I find one of these local maximums? And all you had to do is follow the line until it intersected with something and you got an answer. If it was not feasible, it actually was

Carter Morgan (25:23)

Yes, yes.

Exactly, right.

Nathan Toups (25:50)

unbounded, it would go off into infinity. And you actually couldn't find a maximum, a maximally correct solution. And a lot of times I think when I'm asking large language models, and this might be just me being a goofball, but I'm like, am I asking this a linear programming bounded problem? Like, is there a bounded context to this? Is if, if, is there a solution that I don't know upon which the intersections of the things I'm asking for

Carter Morgan (25:53)

Yeah. Right.

Yeah, yeah.

Nathan Toups (26:19)

have maximally correct thing. I've noticed that if I think that way, it helps me frame the context, the prompt that I'm writing, and I get better solutions out of my large language model. If I ask it something like, so a bounded example would be, given this much, if I was gonna write a large language model that traded stocks or something, right? There's a way I could bound the context of saying, you have this much budget per day, you can access these new sites.

given all of this information, give me the best trading strategy for whatever, right? I'm not saying this will be effective or that it'll be good, but it's bounded in which I've given criteria upon which you can find the maximal thing. But if I just say, here's $1,000, make me a million dollars, right? That's not feasible. That's an unfeasible thing that's gonna go off into infinity. yeah, that's very interesting to me. anyway, yeah, make them, right.

Carter Morgan (27:15)

Make a million dollar business. Make no mistakes.

Nathan Toups (27:18)

And that's a non,

Carter Morgan (27:18)

Yeah.

Nathan Toups (27:19)

you think about it, that's not feasible, right? That's not a feasible linear problem. And so I try to think about like, again, this is the next best token guessing machine. If I can give it a bounded region, then it will probably give me good tokens it's guessing. And if I give it an unbounded region, it's just gonna make up whatever, you know, it's just gonna riff and do its best to do something that's unfeasible.

Carter Morgan (27:39)

Yeah.

Yeah, this is a, this section of the book is very much about kind of like decomposing large monolithic code bases into microservices. That's another thing with this book where it's a little like from everything that like it's using that sysop squad as the, the, the case study here, right? And from everything they've mentioned about the sysop side applications, like it seems like the right move.

Nathan Toups (28:03)

Mm-hmm.

Carter Morgan (28:12)

It seems like breaking it apart in the microservices would be really helpful here. It's just funny because like microservices have fallen like out of vogue a little bit. ⁓ and so just kind of like, as you're breaking apart the, this service, like, again, it all falls and that's what this whole book is about. It's about trade-offs. It's about understanding it's about fundamentals. And I think this is just, you kind of talking about like bounded context and like when like working with LLMs like, yeah, like

trying to not just let them wander off into absolute insanity, But you have the same thing with like breaking apart a large system, which is like, you can get really funky with it. You'd be like, you know what? Lambdas. This whole thing is just gonna be a bunch of lambdas, right? It's like. Yeah, yeah, yeah, exactly.

Nathan Toups (28:59)

And I've seen this.

I recently, so I was doing some subcontracting work with a really great company that does managed Kubernetes for like non-trivial Kubernetes deployment. So these are big, you know, folks that are doing like large scale financial analysis type, you know, data science teams that have to, they can't just use off the shelf tools. They have to build some stuff. But I've also, there's also startups that are in,

several of them, you can see what phase in time the trends were. And one of them was literally like several hundred lambdas, right? And, but there wasn't like good configuration management for us all over the map. was just like complete madness, but it was serverless, right? Like that was what, that's what they're showing. They can't reason about the system. There's no distributed tracing. There's no like all this stuff. And you're just like, this seems awful. Like you can't reason about the system at all.

Carter Morgan (29:30)

Right, right. ⁓

Yep. Yeah.

that boy

is it serverless. Mongo all the time. said, we don't know anything about Mongo. We just know it's web scale. That's all we know. ⁓ Yeah. so like, think having that kind of strong judgment and they give you good tool.

Nathan Toups (29:55)

Right, but yes. Yeah, this thing scales to zero. Yeah, exactly.

Carter Morgan (30:21)

One thing I love about reading books like this is when they give you a concrete way of thinking out something that I'd kind of fuzzily understood or had as instinct, right? And I really liked what they'd called ⁓ granularity disintegrators and integrators, which is this idea of like, okay, you've got this giant surface, you gotta start breaking it apart. But the question is where and how, right?

Nathan Toups (30:41)

Yes.

Carter Morgan (30:50)

And at least as of yet, it's not something kind of thing, a large English model can just spit out at you. And so you've got to use your judgment. Like how are going to break this apart? ⁓ rather than just being like, you know what, like, I think all these files start with F, all these files start with G, right? Like, let's break it apart. Right. they, talk about like, okay, granularity disintegrators. Like what are, ⁓ what are the pieces? Like, what are the qualities that kind of demand?

be broken apart and granularity integrators, like what are the qualities that demand that a service be kept together? So for example, granularity disintegrators, one of them, super simple, service scope and function, right? Which is that like, if you have in your monolith, ⁓ services entirely for shipping and routing orders, and then you also have services for notifications after an order has been shipped, pretty easy to look at those and be like,

You know what? Notifications is just completely decoupled from shipping. And so let's split those apart. But then you kind of look at notifications and I think this what the example uses. It's like, okay, we've got push SMS and letter, you know, like physical letter notifications, right? And then you guys start asking yourself, how similar are these? Right. and even when you get down and say like, okay, like service scope and function makes a lot of sense. Another one.

Code volatility, like how often is this code changing? ⁓ We actually were talking about this with our migration. And I think if we could have done it all over again, because with the migration, we are switching from Mongo to Postgres. And so we have like this little replication engine and we code it. That's like watching the Mongo change log, inserting it into Postgres and then replicating with the trigger functions into the right shape. And so we decided we're like, we don't, we hate this replication engine. It's actually worked out really well, but just like it's a weird pattern.

Nathan Toups (32:23)

All

Carter Morgan (32:49)

Like we're in this world where we're reading from Postgres but writing to Mongo. It's insane. So we want to get off that as soon as possible. We can't do that until we deprecated the entire Java service. And so we were like, okay, let's just move everything over. And then we got to the order functionality, just taking orders and making and processing payments and things like that. And it is by far the most complicated legacy part of our system. And it's a part of our system that doesn't change hardly at all.

the logic for like processing orders is fairly baked in. And so it's consumed probably four weeks of engineering time, not the whole team, but four weeks of man hours, I guess I should say. And I was saying, I'm like, you know what? We're too into it now, we just gotta finish. And I'm like, if we could have done this all over again, I'm like, I wouldn't have touched this. Instead, or I said, I would have touched this, but all I would have done.

is I would have just looked at the Mongo rights and transitioned them to Postgres rights in Java. But I said I would have kept everything else the same. ⁓ And so kind of when you look like, I think kind of service, scoping, and function, and code volatility, I've been like, it would have been fine to keep this running as kind of a legacy GraphQL system. We could have just said like, hey, everything that processes payments or takes orders is on the legacy system. It's not a high throughput enough.

Nathan Toups (33:52)

Right.

Right.

Carter Morgan (34:13)

Service for us to be concerned about its scaling implications ⁓ Which is why we had to do the rewrite to begin with ⁓ Anyhow too late now, but you know, maybe if I had read this book a couple weeks earlier I might have said like, know what? Maybe we should I think we could get away with isolating this and not migrating at least this part

Nathan Toups (34:35)

Yeah, again, this gave really good, it gave a really good breakdown of just how to think through the problem, right? Some of this is organizational, some of this is like the, know, they also bring up code volatility, scalability and throughput, fault tolerance, security and extensibility. And they are, every one of these are trade-offs, right? It depends on

If you have critical security stuff, you know, that I think one of the examples they have in here is like, I have, have PII or we have credit card information. It's really important that who has access to this data in the database is segmented and auditable and all these other things. And so there's this debate, you know, in some of the storytelling between the security team who had these very clear ideas of who could have access to what. And it was...

dictating the way that the system was going to be architected. ⁓ But it turned out that that was actually going cause a lot of problems. And so they had to negotiate, OK, well, what if we didn't fully decouple it? What if we had it this way and we had to extend who has access to the system? ⁓ So the security window had to open up a bit, but it stopped us from having this unacceptable processing time. And again, I like this book because it gives those debates where there's no right

answer, you know, it really comes down to like, well, what's going to impact the business the most, right? That might be that might actually be the thing that pushes your decisions one way or the other, right? ⁓ And it's also nice because it's not just giving examples of like, here's this beautiful soft architecture. You're like, wait, have groups of humans who all have their own wants and needs and fears.

Carter Morgan (36:01)

Yeah, yeah.

Nathan Toups (36:25)

And you have to solve for that too. It's like, we can have the perfect architecture, but we're going to go out of business in six months if we sit here and make the perfect system. And that should be considered. You have to consider that ⁓ in here.

Carter Morgan (36:25)

Yeah, yeah.

Yeah. Yeah.

I'm always skeptical when I hear, like really in any context, but like software engineering in particular, like when I hear engineers telling stories where they are clearly the good guys and everyone else is just an idiot,

right? I'm just like, it's not, it's rarely that simple. Like I'd say what I'm doing at work right now is probably the clearest case I've ever seen in my career of like, I think what we're just replacing this with is just better.

Nathan Toups (36:52)

Yeah.

Carter Morgan (37:07)

But even then, there are several things I can point to. One, like this order service where I'm like, I don't know, maybe we should have just stopped that running. We've such an event-driven architecture, which has given us a lot of good leverage, but we had an issue yesterday where something had gone wrong with the event processing and we had to replay the events. But we had never run into that before. And so this was like a new paradigm the whole team had to learn. And yeah, like, so.

Yeah, I just, you know, I hear too many engineers just like everyone I work with is an idiot. I'm like, one, work better places, right? I guess if everyone's an idiot, but two, like, what are the odds, right? And then, oh, okay, I got it.

Nathan Toups (37:43)

Great.

Right? Yeah, I We all know these people

in our lives, right? That there's always drama all around them. And I'm like, there's one common thread in all of this. Like it could be that they just really were unlucky and that there's just a lot of drama around them. Or you might be a catalyst for that drama.

Carter Morgan (37:54)

Yeah, yeah, exactly. Right. Yeah.

Yeah.

Well, with granular integrators, talk, or disintegrators, they talk about granular integrators, which is like, okay, so what demands that a service we put together? The biggest one I thought was database transactions, right? If it is essential, trivial example, right? But if you can never update the first name without updating the last name, right? Then do not have a first name service and a last name service, right? You need have a name service that owns both of those. Have you ever seen a...

Nathan Toups (38:11)

Right.

yeah.

Right. Could you imagine?

Carter Morgan (38:33)

Chris Am's microservices video on YouTube. ⁓ I'll link it. If you don't watch Chris Am's stuff, listeners, he's like a software engineer sketch comedian. But his stuff is really, really funny. my favorite comment on a video of his was someone replied to like.

Nathan Toups (38:38)

I bet I have, I don't remember. Yeah, I don't remember anything from it.

Carter Morgan (38:59)

The ratio of how good this is to how many people I can show this in my life is so screwed up, right? Cause like, I love it. Okay, yeah, okay, yeah, you're looking at it. ⁓ Yeah, but, but yeah. But it's like, it's like, don't, I don't get it. How come it's so hard to add the, the user names or the user's birthday to their profile? And it looks like they're microservices architecture about like why it's so complicated. Anyhow, ⁓ but database transactions are,

Nathan Toups (39:06)

I remember this video now. Yes. ⁓ it's so good. I ⁓ need to go back and watch more of his videos. That's great.

Carter Morgan (39:29)

a granular integrator, right? If there is some data that must be updated at the same time with ACID compliance, that's a really strong indicator that you can't have them in distributed services, right? And I'll also say like, it surprises me how, I think there's a bit of magical thinking among software engineers sometimes, not about those who,

or at least trying to be serious about our craft, right? But even something like this, like a database transaction, I think some people are like, well, it's a microservice. Like, we'll just, we'll call the services, we'll call each other and then we'll get the data and then we'll all write the data, right? But people aren't even asking these questions. Again, I think most serious engineers are, but I've worked with engineers where it's a little loosey goosey. You don't even think about that consideration, but like, what if the data gets out of sync? What if you query the right data, know, service A,

updates the data because service B calls it and then returns data service A returns data to service B, which service B needs to update its database with. What if it fails? And what if the retries fail? Right. And then like now your, your databases are out of sync and your host. So, you know, that's one, a shared code was another, and they talk a lot about like kind of code reuse patterns. ⁓

Nathan Toups (40:37)

All right.

Yeah, it's funny too, because I definitely have software engineers I deeply respect who are like dry maximalists, right? Dry is don't repeat yourself. And I've just never played that game. Obviously, if I have a good abstraction and I can use this for code reuse, that's great. But I'm not like, I will never ever have a similarly functioning piece of code ever.

Carter Morgan (40:59)

Yes, yes.

Right.

Nathan Toups (41:20)

You can get crazy here, especially in distributed systems, and this is one of things they talk about. You can end up getting these weird coupling patterns where you're like, oh, I'm going to make the Acme Co. utils repo, and turns out my 100 lambdas all use it. And so you're like, you don't have 100 lambdas anymore, right? Every time you update the Acme Co. utils, you have to do 100 deploys of your lambdas. Well, you've got a coupled system now, right? Or you have weird diamond dependencies where

Carter Morgan (41:32)

Yes, yes.

Yeah. Yeah, yeah. ⁓

Nathan Toups (41:50)

you're having to manage the migration of the Simver upgrades of 100 lambdas just so that you can get the new version of the user class or something. And so this book does a great example of either being like, those either should be one service because they all really care about how the user class works, or you should really let these services independently understand how they consume user.

Carter Morgan (41:57)

Yeah, gosh.

Yes,

yes.

Nathan Toups (42:19)

And

it's okay. It's okay to have some copying. It's okay for the producer of some user something to like define its schema and put these things out there. And that the consumer maybe is loosely coupled and they say like, okay, well, I find this shape of stuff ⁓ useful. I remember Neil Ford actually talked about this when he was on the podcast that like, you know, if you use things like gRPC, you actually are like tightly coupling.

two parts of your system because you can only interpret the binary data payload of gRPC if both the consumer and the producer agree upon the contract, right? It's like literally in the code and we have a tight coupling. But if I use JSON, ⁓ I can interpret how that JSON is read at runtime. And so again, I'm not saying that one's right or wrong. If you have a big monolithic repository and you have full control of how your microservices talk to each other and you want to use gRPC,

and they just deploy, that's cool, that's an architecture decision you make. But if you have stuff in which you want complete autonomy between service A and service B, it's okay for you to evolve the producer JSON of the user field or whatever, and that the consumer decides, actually, oh cool, there's some new fields here, or there's a breaking change, and I'm gonna preempt this. yeah.

Carter Morgan (43:44)

It's

so funny how, I imagine this is probably most industries, but obviously I'm only into this one, but like the whole history of software engineering is like overfitting and then being like, wait a minute, I think we screwed up there. Let's go back, right? Because like microservices are a response to the overfitting of dry and like service oriented architecture. This idea of like, hey, if we just, you know, never repeat ourselves and we just try to share the code as much as possible, then that'll let us.

Nathan Toups (43:57)

Yeah, exactly.

Carter Morgan (44:14)

not need to write so much code and then we'll move faster because we have to code less. We can just share all these shared tools. And then it's like, well, not necessarily because exactly what you're talking about, Nathan, which is like, okay, so you've got this kind of big monolithic service oriented architecture. There's a user class right in the middle of it. Who owns it? And if you need to update the user class, who gets to make that decision, right? Whereas in like a microservices architecture, it's like, okay, I'm the user services, right?

⁓ Yeah, I am the engineer working on the user service. We're adding a new field. It's not a breaking change. If any consumers downstream want it, that's great, right? And even with things like API versioning, right? You can do breaking changes, right? So long as ⁓ you have proper versioning set in place. But then of course, now you're stuck supporting to... ⁓ And ⁓ getting back to that concept of like...

what I like about Mark Richards and Neil Ford books is just giving vocabulary to things that I definitely fuzzily understood and I think maybe I least think a good amount of people do is architecture quantum or quanta, is this idea of like an architecture quanta is an independently deployable unit. so like you're talking about Nathan, it's like, have my geo utils package or, you know,

Nathan Toups (45:24)

Yes.

Carter Morgan (45:39)

and every one of my lambdas uses it. It's like, don't have 100 lambdas anymore. You now have one architecture quanta, right? And it sucks for you because it's 100 lambdas, right? That's not crazy. It's not crazy to have one architecture quanta if, you know, it's all just like some like Go service, right? And you run, you know, whatever. I live in an NPM world, so I always say with like NPM dev, what do do to run Go?

Like, ⁓ do you have like a script? ⁓

Nathan Toups (46:09)

So

yeah, yeah, go run and there's the go build if you want to just build the binary.

Carter Morgan (46:13)

Go run, okay. Yeah, yeah. Right,

and so that's what, if that's your development workflows, go build, go run, right? And then it's, like, that's fine. Yeah.

Nathan Toups (46:25)

Yeah,

and that's the other part is that, even if it's a complex system physically, like let's say we decide for whatever reason, we do want independently deployable lambdas, and we do want to have this library that's shared across all of them. If you build your deployment system, and so that it's no pain, zero downtime,

rotated and it automatically has some sort of build solver that understands that you're going to automatically push these dependencies up. There is a world in which you could do this, which is not bad. It's just a lot of upfront work on your build pipeline and in thinking about this stuff. I would still push back and say, you probably want a single Lambda code base, even if you're running in a hundred different contexts. Maybe there are ways in which you

send in some feature flags or have ⁓ some CMD that defines runtime context because they have independent scaling parameters. You can imagine some architecture reasons why you'd want it to run in different contexts. I would argue that you probably want the same code base. Again, there's reasons that that would not be the case. One of the things I liked here, and again, this kind of ties into the integrators and disintegrator stuff, they kind of give you this toy example of

customer service, which has these notification pieces built inside of it, right? Like there's an SMS service and an email service and a letter service, like a actual physical postal letter that gets sent out. ⁓ And they were talking about how, you could have ⁓ like, should I have a notification service that kind of bundles all these things up and it kind of just does the Grand Central Station muxer of how does this notification go out? Or

Should I think of them as a profile service and a preferences service and a comments service or whatever? And they just kind of explore through. There's no right answer, right? It's just like, well, how often are the functionalities of the SMS service changing, right? Like that's one of the criteria that you would say, like, should I break this out or should I put this together? And I think eventually they settle on something that I was kind of interesting where they, to the outside world, it was a notification service.

But internally, there was an electronic notification service. So this would be SMS and email, because they were dealing with the same thing. And then they had this postal letter notification service under the hood. And so there was these three services that came out of it. But to the rest of the organization, all they dealt with was the notification service. And you could probably imagine a situation in which notification service is you're not even talking to the notification service. You're probably just like,

putting something on PubSub, right? Or writing to Kafka saying, a user signed up. And then the notification service is just looking for user sign up and going, cool, we're gonna send them the verification email or whatever the thing is. And ⁓ yeah, I liked this exploration because I've definitely been there. I've definitely been like, is this a notification service? And do we just handle all notifications or is SMS the same thing? You have to tackle these things at different times.

Carter Morgan (49:24)

Right, right.

Yeah. Well, and then some of the other reuse patterns, talk about side cars, right? And side cars. Now, my, I am most familiar with side cars from like an observability perspective, right? Which is that like everyone in the company uses the same observability side car, right? And then you just kind of instrument your application with some open telemetry library, right? And then that

It's just very simple. All that knows is I export to the sidecar that's running in the same, not container, but the same kind of ⁓ network as me. And so I just send it to this port and then the sidecar takes care of actually sending it to our observability provider. ⁓ I've heard it for logging to, you ever seen any other sidecars? mean, that's the biggest pattern I'm

Nathan Toups (50:37)

Yeah, so sidecars are cool. This also fits in that you'll, they mentioned it a couple of times here, but there's like this hexagonal ⁓ design pattern that you'll see from time to time. It's like loosely related to domain driven development. ⁓ And it's this idea of like, how do I write business logic with these contract expectations? So like maybe inside of my container, I just log to standard out, right? Standard out and standard error. And then the sidecar understands how to like either scrape that or pull these things in.

⁓ in the SysOps team or whatever is they're coming up with, okay, if all containers log to standard out and standard error, we know that we will look across all containers and have the standard way of shipping logs and telemetry or whatever. Things have shifted a bit. A lot of people now are using open telemetry where it knows to push to an endpoint that we just know from a service discovery, it's just in a place. And again, that's totally a fine pattern.

Carter Morgan (51:31)

Yeah.

Nathan Toups (51:37)

But Neil Ford called this ⁓ orthogonal coupling. They talked about this idea that, ⁓ yes, all of your Kubernetes infrastructure uses the same logging sidecar mechanisms. But what the orthogonal coupling does is it makes it so that no service has to care. I can hot swap Prometheus for Victoria Metrics. And it has zero impact on the runtime for my.

Carter Morgan (52:02)

Right,

right.

Nathan Toups (52:03)

for my code. that is a beautiful, when you have systems like this in place, it's a beautiful thing because otherwise you have to go knock on the door and be like, hey, remember that logging SDK that I gave you? here's a pull request to change this out. It sucks. It's not fun. ⁓ Or orthogonal coupling is just like, use this pattern in your business logic and I will take care of the rest. I will do the rest of it. ⁓ One that's popular, again, from the Kubernetes world is ⁓ sidecars have kind

Carter Morgan (52:14)

Yeah.

Nathan Toups (52:33)

fallen out of fashion because we now have things like eBPF and you have things like Cilium. you will actually, they kind of do some magical finagling at the network layer. And ⁓ some side cars are replaced with things that can be handled like at the Linux kernel layer. And you can just insert in the hot network path all kinds of like weird, interesting routing.

Carter Morgan (52:55)

Okay.

Nathan Toups (53:01)

And so what you'll end up seeing is ⁓ that it was very popular to have Envoy, which was a reverse proxy sidecar, where you could do all kinds of really crazy service mesh stuff. And that layer has shifted. So now I can actually have a more high-performance network layer where I can avoid some of the sidecar logic. ⁓ But it's the same thing. Again, it's basically using some high-performance optimizations in lieu of

what we were using side cars for. ⁓ But yeah.

Carter Morgan (53:34)

think a lot ⁓ about, I took like ⁓ a human computer interaction class during my master's degree. ⁓ And so a lot of it was kind of like design philosophy. And I think a lot, can't remember who said it, but he's someone kind of famous in the design world. his ideas, they say like, there's no such thing as user error, right? Like if a user misuses your system, like it's because it wasn't clear enough to them what they were supposed to do, right?

I actually think like a good example is like the iPhone, which I think iOS has got a more complicated, more bloated, but like, think it says a lot that like my baby loves reaching for my iPhone and whenever I can get ahold of it, like he can navigate it fairly easily, right? Which like is a real kind of user experience when, but I think there's a similar thing going on with developer experience. And I think sometimes we as developers, we'd like to make things complicated.

We like to be like, ⁓ you just can't understand our developer or development patterns, right? And you you'll get the hang of it kid. But I think we should, we should consider ourselves grateful because I actually think like, is it a pain to develop on this stack? Is it a pain to develop it in this code base is actually a pretty good barometer for like, are we doing things properly? Right? And so if you're finding things like

I need to change the user class and that's going to be like a nightmare. It's like that's a code smell. You know if you are. Yeah, if you find that. You are really really tightly coupled to ⁓ like very very basic functionality and so like you can't ever just run your service locally, but you actually have to spin up like four other micro services so they can all talk to each other like.

Nathan Toups (55:29)

Right.

Carter Morgan (55:31)

That's a code smell that that's a sign that maybe like they maybe this was separated, not along the proper fault lines, or maybe it's a code smell that like you need to get better at mocking things. ⁓ you know, I also say that has been really cool in like an LLM world. Like we are, ⁓ we have vibe coded a lot of little like Dev X utility scripts and just like little bits of tooling to make our lives a lot easier. It's the sort of stuff we're like,

Nathan Toups (55:42)

Right.

Carter Morgan (56:00)

If I had come in and seen it in a pre-LLM world, I would have been like, wow, this team is really, really thoughtful about their dynamics. Like they really, really invest time in this. ⁓ And it's funny because like, I think we saw our thoughtful, you know, because we've created these things, but like, it's hardly any time at all. I'm curious as it goes along, like I do worry a bit about like just having like 95 utility scripts and no one knowing what they do. But at this point, because it doesn't actually enter production, it's a trade off.

willing to make. We can clean up the craft later if we have to.

Nathan Toups (56:31)

Yeah.

It's funny, I've actually found that with these agentics, I've like, I build more little command line tools because they, it's such a good interface. Like it's just, again, Unix philosophy turns out that it's, you I actually, custom command line tools plus skills are better than MCPs in a lot of cases. ⁓ And though I'm not hating on MCPs, they're great ⁓ when you need them. ⁓

Carter Morgan (56:38)

Yeah, yeah.

Yeah.

Yeah.

Yeah. Isn't that crazy?

Nathan Toups (56:58)

I'm working with a client and I recently realized we have Claude Code for Business through the Microsoft there at Azure shop, which is relatively new for me. I I've done some Azure stuff, but not at this scale. And what's cool is that the Claude is automatically hooked up to the Office 365 MCP. And you have to authenticate with it, but it gives you access to like, oh, I need to like, I was in this meeting earlier and you have the transcript and I can just like in Claude Code.

Carter Morgan (57:11)

Okay.

interesting. Yeah.

That's cool, yeah, yeah.

Nathan Toups (57:27)

bring up the meeting that we recorded and I'm like, this is the best thing ever. Okay, cool. Now I'm making Azure DevOps task out of this, right? Like that part's been really kind of fun because that's toil for me, for sure.

Carter Morgan (57:30)

Yeah.

There's some stuff about distributed data access. We've kind of touched on it throughout our discussion. Anything you want to cover before we head out?

Nathan Toups (57:47)

Yeah.

Yeah, yeah, yeah. it is data ownership for distributed transactions and then distributed data access. I liked this because there was a lot of these edge cases. You're like, well, actually, this gets a little complicated, like ⁓ exploration of the data domains, which we haven't given enough justice to in this conversation. But it's probably some of the most powerful stuff in this book. You have to spend time with it.

I really thought this was by the end of chapter 10 or for the physical book or chapter 17 in the audio book, we now start to see the team is actually getting better at riffing off each other. And there's a lot more like trust of like, can you defend your idea? Is this thing actually justifiable? Which it's kind of fun because we're maturing along with the team on how they're justifying the design decision they're making. So yeah.

I don't know. We actually left off on a really good spot. I'm excited to round out the end of the book.

Carter Morgan (58:54)

Yeah, I'm excited too. Again, kind of another classic Mark Richards, Neil Ford book. And then I don't want to do this service to promote Sada Lage and Jamak Deghani. Obviously their contributions are much appreciated, but ⁓ I get the impression that Mark and Neil have more of a close working relationship. And then they bring on others as like subject matter experts. I know that's a ⁓ promote job. He's a database expert.

Nathan Toups (59:15)

Yep.

Exactly.

And I will say a lot of the hard parts of this book are dealing with databases, right? So like they spend a tremendous amount of time because these are the stateful parts of the system. Stateless parts of the system are relatively easy to decouple, right? OK, you know, it's maybe a route or these other things. The stateful parts are hard. And this is why the book sort of, I think, spends so much time thinking about it.

Carter Morgan (59:43)

Well, let's, I think as far as our hot takes go, mine was just, yeah, dry, like dry basically to me only applies, I said in your code base, but I actually kind of, think the better way to think about it is an architecture quanta, right? For the most part. I think it's great not to have seven functions that all calculate the price of an order, right? But like we talked about, don't do your, you know, it's okay if you re-implement the user data transfer object shape.

across multiple code bases. I have another hot take, but it's not related to the book. So why don't you give me yours first and then you go.

Nathan Toups (1:00:20)

Okay, so yeah, I got two,

both are pretty short. One's similar to the thing. There's a go proverb, which says a little copying is better than a little dependency. So go actually takes the kind of contrarian view that, hey, you really need to justify dry. You lose optionality. And that actually vendoring stuff, so like there is no left pad problem in go, because you're just like, hey, I'll just make a copy of that and just maintain it myself. That's totally fine.

Carter Morgan (1:00:33)

Yeah.

Nathan Toups (1:00:49)

And that fits into distributed systems really well. If it's trivial, ⁓ you should just have your own implementation. ⁓ And then the other one is, this seems like an awfully small team for the amount of services we're breaking things up into. And I know that this is a toy example, but some of this I do think that we've pendulum swung back to being like, do you really need this? So yeah.

Carter Morgan (1:01:04)

Yeah.

Yeah, yeah.

And that's kind of my rule. I don't think I would do more than one microservice per team, but then it's also hard like reorgs. If I'm ever in charge of something, we're never reorging. Not that like, I'm sure I'll be in charge of something and we'll reorg one day, but just the more I learn about just kind of like team dynamics and like maintaining code, like I'm just shocked. Like the first company I worked at, like a Fortune 500 company, we reorg like every six months. I'm just like, what is this? Anyhow, so whatever. Other hot take.

This is not, it's related to some of the LLM stuff we talked about, but not necessarily related to the book. I've just been reading Twitter yesterday and Opus 4.7 is out, not 4.6. And we've noticed this at work, 4.6 Claude seems to be degrading a bit. And 4.7 is like weirdly combative. Like if you don't take the right tone with it, it'll just stop working. It's weird. Yeah. Like I actually,

Let me pull it up. I saved it from earlier. Yeah.

Nathan Toups (1:02:14)

That's amazing. Yeah, while you're pulling

that up, I started using 4.7 yesterday. I've been playing with a new plugin, or new to me, called Superpowers. It's been really nice for doing like sub-agent work. And so far, 4.7 has been awesome for that. But I'm also running it on like extra high because I'm crazy. I'm not on max because that's like a token gobbler.

Carter Morgan (1:02:37)

Yeah.

Yeah. But like, look at this response. Like someone says, Claude Opus 4.7 misunderstood my tone three times in a row and basically said F off. And this is the response. says, go for it. Genuinely. If Codex or Chad's DBT gives you a better answer, use it. I don't have any stake in keeping you here. I'll just flag one thing before you go. The search I did was real. The results were what they were. And as a different model searching, we'll find roughly the same corpus. And then some other stuff says, take care, Mark. I'm like, geez Louise. Like, what is this? But anyhow.

Nathan Toups (1:03:05)

SAS Factory.

Carter Morgan (1:03:07)

Yeah,

this all reminds me, I remember watching a video from Carl Brown where he talks about the biggest lie the AI labs are selling or like the AI maximalists, which is that like, this is the worst they'll ever be. And he said, that's not true. He says, because he says that's generally true with hardware, but that's not true with software. He's like, was Windows Vista better than Windows XP? Heck is the current Windows better than Windows XP, right?

Nathan Toups (1:03:33)

Right?

Yeah.

Carter Morgan (1:03:34)

He's like, software

does not benefit from the same, like, just improvement, kind of like, very clear linear improvements that, that hardware does. Yeah. But I think that's a great example, right? Like liquid glass, like, is that better than before? And when I first heard it, I was like, I really, really liked Carl and really respect his thinking. But I kind of thought, like, is that cope? Right? Like, I don't know. Like,

Nathan Toups (1:03:45)

Except for liquid glass. We all know that that's the best.

No, I think it's wisdom. I

really do.

Carter Morgan (1:04:03)

And just

seeing some of these developments, I'm like, interesting. Like there's something there.

Nathan Toups (1:04:07)

Yeah, I, yeah.

Right, because you look at Apple and you're like, they looked at all of ⁓ UI interface history and they're like, let's copy Vista. Let's copy Vista's liquid class.

Carter Morgan (1:04:17)

Yeah, I know, right? I

say liquid glass is great if you've ever looked at your phone and said, I wish everything were just a little blurry. yeah.

Nathan Toups (1:04:25)

Right. Yeah, I'm just like,

there's so much screen real estate because I got the newer phone this year and I'm just like, ⁓ come on, whatever.

Carter Morgan (1:04:33)

I know, right? And then like the

photos app rework they did, they've repaired the photos app and it's better now, but anyhow.

Nathan Toups (1:04:40)

It's never

been a better time to use Cal Newport's advice and use your phone less. So there you go.

Carter Morgan (1:04:45)

Yeah, exactly.

and you know, just, just a little thing I've been thinking about and I'm just like, interesting, like Carl's, Carl's take that like this is software and software is not guaranteed to improve. I don't know. That's we, if you're listening to this like years in the future, um, we really want at book overflow to make evergreen content. And we do really strive for that. And most of this episode was evergreen. Some of the large language models stuff, um,

I feel like we're making a bit of an exception for, because one, this is genuinely a very uncertain time in the industry. I don't feel a ton of uncertainty in that, like, are we going to have jobs? But I do feel lot of uncertainty in this sense that like my job might look very different five years from now. And it certainly looks very different today than it did five years before. And also a lot of. It's like most of the content on AI online is generated by like the AI maximalists and the AI hype guys. Right. And then there's like.

I think too many people that are just way too AI skeptical. And I feel like there's not enough discussion from like more of that middle ground. And so yes, there's a bit a bit more AI content in some of our more recent episodes. Part of it is just cause like it's on at least my mind. I'm sure it's on your mind, Nathan. And so it's just coming up. But the other part is just that like one thing I really like about Book Overflow and I like about our community is I feel like it's a community of

really earnest professionals who are just trying to do a good job and just trying to be better at their craft. ⁓ I think in a very uncertain time like this, it helps for us to kind of all do a bit of processing together. So our apologies for the ⁓ pollution to what we hope is evergreen content, but hopefully this also serves as a fun, ⁓ you know, just like this book is a little frozen in time and serves as a fun artifact of its time. So will this podcast.

Nathan Toups (1:06:35)

Right.

Yeah, if I went back in time and somebody was debating like VHS versus Betamax, I think that was like a fun little snapshot in time.

Carter Morgan (1:06:43)

Yeah, yeah, right.

That'll be weird. I had never even considered this, but like, I don't listen to our work, right? Like, I listen to enough to edit it, right? But like, I'm not like, boy, new book overflow. Let me listen to this on my commute. But I wonder if like 10 years from now, I will fire up these episodes and be like, what was Carter 10 years ago thinking? And that could be fun, right? Anyhow.

Nathan Toups (1:07:05)

Yeah, yeah, that would be kind of interesting.

Carter Morgan (1:07:10)

What are we gonna do differently in our careers, Nathan? ⁓ We didn't mention it in our discussion. They talk about like kind of the Gang of Four. Like there's a ⁓ design pattern book called the Gang of Four. I'll be honest, I don't know what the Gang of Four is, right? But we've been talking about it at work. We use the strategy pattern at work, which I believe is one of the Gang of Four. And one of my coworkers is really high on the Gang of Four. And it's very rare that someone's read a software book that I haven't. And so they mentioned again this book, I'm like, I should just brush up on like what those are.

you know, it's come up enough in my work that I need to hammer this out. So that's me. How about you, Nathan?

Nathan Toups (1:07:46)

Yeah, I'm in the same bit. I'm like I know of the Gang of Four. I will tell you there was a period of time where I assumed that the Gang of Four were four people that had some ideas. ⁓ Yeah, there's this tough gang coming up with great ideas. ⁓ No. ⁓ It's the next superhero movie. And ⁓ I want to I my goal is I want to get more familiar with ⁓ DDD, which is the

Carter Morgan (1:07:55)

Yeah, Uncle Bob, John Osterhout, Stephen Wolfram. I'm putting together a team.

Nathan Toups (1:08:16)

domain-driven ⁓ development. And ⁓ we have a book coming up in the future that's gonna be talking about this, but there's a lot of like tip of the hats going to the ideas in that book that I know that because of my lack of depth in this, I'm not completely ignorant about it, ⁓ but there's a lack of, because I have a lack of depth, I don't quite get the sort of like,

nods that are going to everything. So that's something I'd like to brush up on even before we read the book. ⁓ Yeah.

Carter Morgan (1:08:52)

There we go for book recommendations. ⁓ I'd say the same as last week, we agreed. Just those really into software architecture, advanced software architecture. ⁓ I would say absolutely read fundamentals of software architecture first. ⁓ but this is a great book and you know, we've said it plenty of times at this point. I'm a big fan of Mark Richards and Neil Ford's writing and, ⁓ you know, they bring so much expertise and then a very digestible, ⁓

easy to read writing style, but at the same time, it's not talking down to you at all. It treats you like the professional that I think they are hoping are reading this book. So a big plus one there. So any, serious architects out there read fundamentals and then read this.

Nathan Toups (1:09:33)

Yep, I'm in the same boat. Fundamentals, I'm also, I think there's like the trilogy now in my mind, which is fundamentals, evolutionary architecture, and the hard parts. I think if you read those three and you're really trying to like beef up those architecture skills, or let's say you've been put into position where you have a lot of software architecture expectations, you, particularly if you're in a Fortune 500 company, you'll be MVP really quickly with those three books.

Carter Morgan (1:09:57)

Right.

There we go. All right, well, thanks for listening everyone. We'll finish up discussion of this book next week. ⁓ You can always catch us at bookoverflow.io. can find us, you can email us at contact at bookoverflow.io. I'm on Twitter at Carter Morgan, the podcast on Twitter at Book Overflow Pod. Nathan has worked with functionally impaired, or sorry, with Rojo Roboto, his consulting agency is at rojoroboto.com. And you find his newsletter at rojoroboto.com slash newsletter. Thanks so much for listening everyone. We will see you next week.

Nathan Toups (1:10:33)

See you.