In this episode, Charles and Valentino dive into the complexities of software design decisions with the esteemed guest, Uncle Bob Martin. They explore the pivotal question: How do you evaluate frameworks and dependencies in your projects? Uncle Bob shares his seasoned perspective on choosing frameworks based on an application's long-term goals and complexity, emphasizing the importance of thoughtful decision-making over defaulting to popular solutions. Together, they delve into the nuances of evaluating framework capabilities, testing with small demo applications, and considering AI's potential in refining design decisions.

You'll hear gripping anecdotes from Uncle Bob's vast experience, including his work on a browser for a social network and valuable lessons from his commitment to frameworks like Swing. Valentino adds real-world insights from his encounters with framework-induced slowdowns in complex financial applications. We also touch on historical programming practices, the importance of thoughtful abstractions, and the critical role of experienced team members in guiding projects.

Stay tuned for fascinating discussions on managing dependencies, simplifying core problems, and balancing framework used to ensure flexibility and maintain development speed. Plus, don't miss the exciting announcements, including Uncle Bob's upcoming books and special discount offers from Charles Max Wood. Join them as they unravel the intricacies of software design decisions and share tools and strategies for modern developers!

Valentino Stoll [00:00:04]:
Hey. Welcome back to another episode of the Ruby Rogues podcast. This week on our panel, we have Valentino Stoll.

Charles Max Wood [00:00:11]:
Hey now.

Valentino Stoll [00:00:13]:
I'm Charles Max Wood from Top End Devs. Just wanna do a quick call out. Aidevbootcamp.com. If you sign up within the next few weeks, I'm doing a 45% discount because I turned 45 on Saturday. And, yeah, Bob's laughing. I'm I'm gonna take a little personal license here. So, there's a there's a political party. I'm I'm in county leadership, and, we were talking about youth outreach, and our party secretary is probably pretty close to Bob's age.

Valentino Stoll [00:00:45]:
And, so we were chatting and we had, like, this 22, 23 year old, young woman who was talking to us about reaching out to to younger people. And, somebody goes, so when we're talking about youth, what are who are we talking about? And he chimes in, and he goes, anybody under 45. And so, I I felt young for, like, a week and a half, and then I turned 45. So So, anyway,

Uncle Bob Martin [00:01:08]:
the wheel now.

Valentino Stoll [00:01:09]:
That's right. I'm old now. So, anyway, we we also have uncle Bob Martin or Robert c Martin as people know him. Bob, do you wanna just say hello and let people know what you're up to these days?

Uncle Bob Martin [00:01:20]:
Hi. Yeah. What am I up to these days? Well, I'm in the midst of writing the second edition of Clean Code. My publisher said, you know, you should do a second edition, and I thought, that's probably a good idea. It's been about 16, 17 years.

Valentino Stoll [00:01:38]:
Yeah.

Uncle Bob Martin [00:01:38]:
So first draft is off to the publisher. They're gonna send it out for review, then we'll do another scan through it, and I imagine we'll see it out mid next year.

Valentino Stoll [00:01:49]:
Good deal. You also released, and and this came up on the JavaScript Jabber Show, and I was excited for it. And so we're definitely gonna have you back on this show and that show to talk about it, but you released another book about, historical programmers.

Uncle Bob Martin [00:02:05]:
We programmers is the title of it. The the publisher thought maybe We the Programmers was a little too, much like the declaration of independence or the constitution or something. So it's called We Programmers, which is a nice takeoff on Asimov's I, Robot, I suppose. It is a a history of software programmers, starting with Babich and then walking through the early 20th century, early to mid 20th century. So we get people like Dijkstra and Hilbert and Von Neumann and Turing and and Grace Hopper and John Bachus and and, of course, the, the c trio, Dennis Ritchie and Ken Thompson and Brian Kernighan. And and I I focus on the technology. This is a book for programmers. So I talk about the the machines themselves, you know, how many bits they were, their cycle times, what did the instructions look like, what kind of problems were they solving, how much memory did they have, what what kind of memory it was.

Uncle Bob Martin [00:03:17]:
And I also focus a lot on the the personalities of the programmers, specifically their life struggles, because all of these people were human and they were really interesting humans. They all had, in the midst of this really deep technological struggle, they also had very human struggles. So it's a book about the human side of programmers, but with enough technology to to attract the attention of programmers. So that's that's how the book goes.

Valentino Stoll [00:03:53]:
Yeah. Well, it's it's interesting to me just from the standpoint of, yeah, I mean, they they're essentially doing what we do. The the difference, I guess, is that and and this is the thing I like about good narratives, you know, a novel or whatever anyway, is that, you know, their challenges were different. They were inventing new ways of doing things. I guess the difference between some of the other books that I read in this is that we're you know, unless it's a historical novel like this or, you know, has to do with the past. Right? We're still dealing with some of these things or we benefit from the way that they invented to solve them. So

Uncle Bob Martin [00:04:30]:
You it's easy to to draw a line. If you if you look at the technologies and if you really dig into the technologies, it's easy to draw a line from there to here. Right. And that line is this exponential curve, which we called Moore's law back before Moore's law died. But it's very interesting to you you look at the the earlier mechanical machines and then the electromechanical machines and then the vacuum tube machines and then the transistor machines, then the integrated circuit machines, and you you can transistor machines, then the integrated circuit machines, and you you can see this interesting curve. And the same thing happens with memory, you know, originally memory was just in gear positions, and then later on it was sound waves through tubes of mercury, and then it was charged dots on CRT screens, and then finally it was core memory, real core, magnetic core, and then finally, you know, disks and solid state memory. So very, very interesting. And if you if you follow the deeper technology, you can see that thread really easy.

Uncle Bob Martin [00:05:35]:
And you can see the struggles of the, the hardware architects. They had no idea what programmers would mean. So the early machines had no way to call a subroutine, no way to store a return address, no way to,

Valentino Stoll [00:05:49]:
to

Uncle Bob Martin [00:05:49]:
put anything on a stack. Right? The earliest machines had no jump instructions. They were just linear linear steps. And if you wanted to, if you wanted to have a loop, you would take the paper tape which drove the machine and you would back it up and then let it run forward, and then you'd back it up again.

Valentino Stoll [00:06:08]:
Oh, no way.

Uncle Bob Martin [00:06:10]:
Yeah. Yeah. Yeah. And the operators would have to check the registers to see whether or not the loop exit condition had been achieved. But, you know, when you're only executing 10:10 instructions a second, you can do that. And, you know, a good program will run for 80 hours with with constant operator intervention.

Valentino Stoll [00:06:34]:
Well, I have to say, I I'm living a charmed life.

Uncle Bob Martin [00:06:40]:
Yeah. Here we are communicating over the ancestors of these machines, you know, whipping bits around at a rather impressive rate.

Valentino Stoll [00:06:50]:
Yeah. That's amazing.

Uncle Bob Martin [00:06:53]:
Yes. It is. Oh, yes. Exponential curves cool. Yeah. Definitely have an effect over time.

Valentino Stoll [00:07:04]:
Yeah. Yeah. Anyway, it it's great stuff. I actually invited you to come on and talk about, and it's this snippet. It's like, what, 3 minutes? But it it was it was interesting. Oh, Taras on, on x says, so that's where you rolling your own loop comes from.

Uncle Bob Martin [00:07:29]:
Yes. They actually did do that. They would, put the paper tape into a loop. They'd scotch tape it together.

Charles Max Wood [00:07:37]:
Yeah.

Uncle Bob Martin [00:07:37]:
Yeah. Except one time, they twisted it, and then it was a mobiles strip. Didn't execute well.

Valentino Stoll [00:07:45]:
Alright. Well, let let's dive in. You see so this is video. I don't know if you posted it or somebody clipped it from a talk you gave, but it's a sent

Uncle Bob Martin [00:07:55]:
from a talk. Yeah. Yeah. So background music in. Yeah. And there's there's some

Valentino Stoll [00:08:01]:
images that show up, and there's a guy that's Yes. Massaging his temples. Right? Anyway, it it's the problem with frameworks. And what what's interesting, you know, because we had a similar ish conversation on Ruby or on JavaScript Jabber, and so it'll come out probably around the same time as this one. What's interesting to me though is that, like, we you brought up Rails when we asked you about it, and then we, like, totally sidebar into React and Vue and, you know, when all the stuff there and and trade offs with maybe Zwelt or something like that. And the the concerns that we're talking about, you know, the things our frameworks do for us in Ruby are, I guess, some ways similar, but in a lot of ways, it's solving different concerns and different problems. And so I was kinda curious to see if we had would have the same conversation here or if it'd be a bit different just from the standpoint, but, you know, you know, you know, just given the the different technology. So, I keeping that in mind, I just kinda wanna, kinda let let you let it rip.

Valentino Stoll [00:09:13]:
You know? What what are the problems with frameworks?

Uncle Bob Martin [00:09:16]:
Right?

Valentino Stoll [00:09:17]:
Because we all love ours.

Uncle Bob Martin [00:09:18]:
It was Rails that actually put me on this track.

Valentino Stoll [00:09:22]:
Okay.

Uncle Bob Martin [00:09:22]:
Because I had been a, a tepid, Rails programmer for a few years, you know, back when Rails was the big thing. I don't know what year that was, probably 06 or something like that.

Valentino Stoll [00:09:34]:
Yeah. About then. That's when I got into it.

Uncle Bob Martin [00:09:36]:
Yeah. Okay. So and I was diddling around with it, and I wrote a couple of applications for this or that. And then my son showed me an application that he had written, and I was just reading through it. And I noticed that the just the directory structure of his application yelled at me. It just said rails, rails. I'm using rails. And I thought, well, that's odd.

Uncle Bob Martin [00:10:00]:
Why is his directory structure so damned opinionated? And, well, I mean, that's because Rails is an opinionated framework. And that made me think, well, okay. Should it be? Or rather, should I allow Rails' opinionation to influence the structure of my application? Or should I make sure that I keep the opinionated structure of Rails at arm's length? While I go ahead and use it, can I keep all those opinions from leaking into my application and warping my application? And that's really what got me onto the thread of of frameworks. And as I was thinking about that, I thought, well, okay. David is the author of of rails, David Hadermeier Hansen, and he did it for his company. He did it for 37 signal. Right? He was he he did all that for him. He didn't do it for me.

Uncle Bob Martin [00:10:58]:
And the more I thought about that, the more I thought, you know, the more I commit to rails, the more asymmetric this relationship becomes because David is not making any commitment to me at all. He's not promising to maintain rails in the direction I want it to go. He's not promising to give me any features that I want. He's gonna put in features that he wants, and if I like them, fine. If I don't, I can get lost. And he actually put, you know, he went to a conference at one point and he bunch of people at that conference, and up on the screen as he's standing there right behind him were two words. The first one started with f and the second one started with y. And so I thought, yeah.

Uncle Bob Martin [00:11:44]:
I probably don't want to make a big commitment to an author who has no commitment to me. I don't mind using the stuff as long as I can kind of keep it at at some kind of a distance, build a little isolation layer and prevent myself from being polluted and trapped in the, in the opinionated structure that he is properly creating for himself.

Valentino Stoll [00:12:13]:
Yeah. It's it's interesting too. I'm just gonna kind of pile on to this idea a bit. Like, if you go watch the last, keynotes that that David gave at I mean, when we say David, it's DHH folks.

Uncle Bob Martin [00:12:27]:
Oh, for

Valentino Stoll [00:12:27]:
for the people that aren't following along.

Uncle Bob Martin [00:12:30]:
A guy I hold in very high regard, by the way. Right. Yeah.

Valentino Stoll [00:12:34]:
Yeah. I mean, I've I've known David now for several years, and so I I call him David, and I I don't anyway. But he like, if you go watch the talks, right, he's talking about stuff that's terrific stuff. Right? And it's like, oh, I want that. Oh, I love that. Oh, I really but if you if you're paying attention to his talk, what he says is is, hey. We're introducing this new thing, and here's the problem it solved for us at base camp. Right? I mean, all every single thing, it's and and we we had this problem at base camp, and we solved it with this, and now you can use it too.

Valentino Stoll [00:13:10]:
Right? And granted, a lot of those are things that I want solved too, and so I'm perfectly happy to pick them up. But but yeah. I mean, the the truth is is a lot of the stuff that ends up in Rails is stuff that that they need. And then, yeah, they do get contributions from other companies, that have other concerns, and they'll they'll accept those. Right? But, you know, then it's solving some other person's problems contributing to the framework. But the vast majority of the stuff that he goes up and and announces, he he basically says it. This solved this problem for us at Basecamp.

Uncle Bob Martin [00:13:44]:
Yep. And that's great. It just maybe I can use that to solve my problem, and maybe there's a way that I can use it to solve my problem without making a gigantic commitment to it, without inheriting from some base class that they wrote or without, you know, forcing my application to adopt the structure that they want.

Valentino Stoll [00:14:10]:
Yep. Rails magic. What do you think of Valentino?

Uncle Bob Martin [00:14:17]:
It's

Charles Max Wood [00:14:19]:
so it's hard because, the the structure of the application, if if you're a contractor as an examiner consultant, having that be the same for all the applications that you have to look at is such a huge benefit. Right? Like and having a lot of of the things normalized, maybe not everything that Rails normalizes, but, like, the normality of across, like, just like if you're looking at hundreds of applications, right, throughout a year, like, you just save incredible amount of time and context. Right? Like, you don't have to rethink, okay. Well, uncle Bob today decided to use a different, you know, structure because, you know, maybe that it was a more appropriate design decision. Right? But it's different than maybe some of the other ones that, you know, you more typically, will take on. And so you have to, like, then have to reframe your thinking and gain regain context, and there is kind of developer loss across that. Even but that's the trade off. Right? Like, you make that choice up front, and it's your choice.

Charles Max Wood [00:15:23]:
Right? So, but but, I mean, thinking about bigger teams, like, it becomes, like, really hard to, like, start like, where do where do you see, like, in a larger team structure, like, the value in, like, creating, like, the barrier, to the framework? Right? Like, where where do you start to see, okay. Like, we have started to design our pieces of the application separate from the framework. Like, when does that start to take off? Right? And where does where does that, like, really start to fit in, the most obvious?

Uncle Bob Martin [00:15:57]:
Well, I think that the first question that a team would face is, you know, which framework should I use? Should I should I start with Rails? Because a lot of people do. Right? They just say, okay. We're just doing Rails or whatever framework. It doesn't matter. I don't want to pick on Rails too much here. Just, you know, there the whatever the the framework du jour is, they'll say, okay. Let's try that because it's beautiful and it's gorgeous and we can go really fast. And is that the right decision to make upfront, or should you be thinking about, alright, we've got this application and this application has a bunch of requirements, and we're gonna need this kind of data storage, and we're gonna need this kind of computational structure, and what framework out there would help us with this? And is there a framework out there that would help us with this? Or maybe what we should do is write a little bit of it, get get a little bit of it going, and then see if there's a framework that fits into this.

Uncle Bob Martin [00:16:59]:
It would also be nice if the framework would be, less demanding of, commitment. Like, I'd like to use it off on the side. I like to call it a little bit. I'd like it to be more of a library than, you know, forcing forcing me to hand execution control over to it and then it deigns to call me back when it needs to. I might want to maintain control of execution. I might, you know, or I might I might let it go, but I'd like to be able to make those decisions with enough information that I can do so in an informed way.

Valentino Stoll [00:17:42]:
So, yeah, and this is this is kinda where you you began to lose me a little bit because I I just I don't know I don't know how you do this. I mean, do you pick up something simple like Sinatra or ROTA, or or or do you just start building the other pieces of your you know, maybe you build business logic, but I I don't know. What like, what what's the approach here then to putting it off? Because yeah, rails gives me, like Valentino said, it kinda gives me a bookshelf and and tells me where to put my stuff. Yeah. And and it it solves a bunch of stuff out of the gate. And so, yeah, but at the same time, I I really you know, it it it sounds right, you know, especially, you know, I kinda grew up programming under agile development stuff. Right? And it you'll never know as little now or as little as you do now kind of thing. Yeah.

Valentino Stoll [00:18:39]:
And so if I can put it off and then realize, oh, you know, maybe Hanami or something else offers, you know, a different way to think about this that's more in line with what I want. But but how do you do that? How do you start putting the pieces together without the framework then?

Uncle Bob Martin [00:18:56]:
Well, so frameworks solve a particular problem. Right? They help you get things on the screen. They help they help you get things onto a disk, into a database of some kind. They help you talk through sockets. There's a whole bunch of things that frameworks allow you to do. But then you've got your application and your application has other things that it needs to do. There's a reason that your application exists. There are business rules that don't have anything to do with the framework.

Uncle Bob Martin [00:19:24]:
They don't have anything to do with what's on the screen or what's in the database. None of that technology matters to the reason that the application exists. Right? So you can create the the core of an application. You can start with some business rules and you can just put those together. It's not hard to do. There's some calculations you've got to do. There's some, perhaps, some data storage you have to do. And you don't, you don't need to make a commitment to the the screen or the database.

Uncle Bob Martin [00:19:54]:
You can build a little isolation layer that allows you to put things on a database but without knowing what database it is, just a bunch of interfaces that you implement later, you know, and there's some way to get things on the screen. You don't know exactly how you're gonna get it on the screen, but you can at least arrange the data in a way that you know would eventually get on the screen. And you can do all of that without the framework, without you can do it without a database. You can do it without, any of the normal kinds of trappings that you would expect in an application. And then when you've got enough of it done, and it doesn't have to be the whole thing, obviously, but when you've got enough of it done, you look at it and think, okay. What framework out there is really gonna help me with this? I really need to get this on a web page. Maybe you haven't even thought about a web page yet. Right? I really need to get this on a web page, and Rails is great at doing that.

Uncle Bob Martin [00:20:49]:
Maybe I should use Rails. But if I do use Rails, it would be really nice if I didn't have to pull all of that railsy code into my application. Maybe I can put it all behind my isolation layer and then I can call rails happily through my isolation layer and my application is not necessarily affected by rails. This is the way I like to start all applications. I like to start with the business rules first and then start feeling outwards and see how much how much of a framework I need. In the in the last one, I told the story of fitness. And in in fitness, you know, that was a web application. It's a Wiki, and it's got a database or at least we thought it would have a database.

Uncle Bob Martin [00:21:34]:
And we as we planned the whole thing out, we thought, well, we're gonna need a web server, and there's a couple of open source web servers you could get and didn't have a big framework in those days. But, you know, the GNU project had a bunch of I think Apache had some web servers back in 2000 when we started this. And we thought, you know, maybe we'll get a database, and we had, we thought we'd get MySQL because, you know, why wouldn't you? And then and then we just started building, but without any of that stuff. We just started building. Just and and what do you do with the Wiki? The first thing you do is translate Wiki text into HTML. Well, okay. That's pretty simple. Don't need you don't even need a web page for that.

Uncle Bob Martin [00:22:16]:
You don't need a web server for that. All you need to do is look at the HTML. And if you want to get it up on a web page, it's awfully simple to get a browser and have it, you know, pull up some HTML from a flat file or something. So that was very simple. And at some point, we thought, well, we've got to get it up. We got to talk to a browser. We've got to be able to talk to a browser. Something's got to serve these web pages that we're building.

Uncle Bob Martin [00:22:43]:
And we thought, well, let's let's go look at, let's go look at the Apache thing. And then and then we thought, well, how hard is it to build a web server? Well, it turns out that's about 300 lines of code. It's not very hard to serve a web page, which is really all you're doing is opening up a socket and throwing stuff out the socket. And we thought, well, why don't we just do that for the time being? You know, maybe we'll get Apache in there later, but for the time being, we've got 300 lines of code and it puts up web pages just fine, and we kept on working on translating the markup. Eventually, we needed a database and we thought, well, we could get MySQL going, but be awfully simple to just store all these pages in a hash table, you know, and that kind of looks like a database from the outside looking in. You can you can make calls against the hash table that look like a database query. So we built a little interface that looked like a database query and put a hash table behind it and kept on working and working and work. Got the whole doggone program up and running, the whole wiki and all of the stuff that it was doing with lots of extra stuff that we were doing in fitness.

Uncle Bob Martin [00:23:52]:
And, we didn't have a database, and we had our own little tiny web server. And then, we thought, well, I mean, we gotta get this stuff on disk somehow because we can't just keep it in a hash table. And Michael Feathers was there at the time, and he just wrote a little thing that dumped it all out to a flat file. And, now we had persistence. We didn't use MySQL for the persistence, and we didn't use Apache for the web server, and we put the whole doggone thing together. It sits in 1 JAR file, and just turned it loose and, you know, people were using it and using it. I think it's still got a fairly significant user base today after 25 years. So that that's a story of how you how I like to build from the inside out and feel my way towards the outside world.

Charles Max Wood [00:24:42]:
Yeah. It's funny you you mentioned it like that, because I feel like from a a reels developer standpoint, it's, like, backwards where Yeah. Absolutely. For sure, like backwards. You think about even just, like, the small design decisions where people you know, you'll create a service object, which is just a class that, like, does one responsibility. But it's really like you have this design as a thing because, like, you have to do something separate from the framework. And there's form objects and all these different kind of objects that people have come up with to augment what they you know, to make their own thing. Kind of like to make a pattern out of, like, you know, something.

Charles Max Wood [00:25:21]:
Because almost like the framework is so, like, you know, opinionated, you wanna make opinionated patterns. And so it does have, like, kind of that translating effect. But I like your your thinking of, like, boundaries for sure. Yeah. I think, like, creating boundaries is, like, super important from, like, an app like, focusing on what, like, you're actually delivering for your users. That's unique. Right? And, like, it's funny because, like, there's there's a Ruby Gem called Packwork, you know, designed by Shopify. And if you haven't heard, it's like, you know, a way of just, like, creating those boundaries in isolation within a real system.

Charles Max Wood [00:25:59]:
Right? So it's like something that was created to snap into a real thing to isolate it from reels, which is just a little bit funny because we're go again, working backwards. And it's and it's super funny to me because, like, you know, this all comes from, like, every everything in real is built on rack, which is, like, honestly, a really great design framework.

Valentino Stoll [00:26:20]:
Oh, yeah.

Uncle Bob Martin [00:26:20]:
Because it

Charles Max Wood [00:26:21]:
has, like, at this bare minimum, it's just, like, you know, individual modules that you can drop or not. Right? And you can add and stack on however many you want. And all of those individual pieces, like, you know, mutate or adjust the stack that it's in, individually and in isolation. And so it's easy to test, easy to swap in and out. And I really like the design of Rack personally, as a framework because it is, like, you know, super modular, which is funny because Rails is termed supposed to be modular. And in a lot of ways, it is. You can start removing you know, if you don't want active record for database, you don't have to use it. You don't have to just, like, use all the standards.

Charles Max Wood [00:27:06]:
And it's funny because, like, that was a common practice, you know, in the early days of, like, even Groupon. Right? Like, you would just, like, oh, you have your your Rails stack, like, explicitly defined in your setup and say, oh, yeah. I'm gonna use all of these things all the time.

Uncle Bob Martin [00:27:21]:
Mhmm.

Charles Max Wood [00:27:21]:
And now it's just like, well, we were just gonna require Rails and be be done with it. And so it has kind of moved away from that. But I'm curious, like, it when you're thinking about, like yeah, I just want to write something to the disc, and that works, and that's fine. Like, as like, let's say, like, something became super popular and you started to have, like, a lot of people working on it and having to, like, get up to speed with all these individual, like, customizations. Like, at at what point where's the diminishing return there? Right? Like, where is it, like, okay. We built all these custom things that people have to manage over time and make sure are secure and and things like that. Like, where where do you stop? Like, do you go down and, like, build a compiler code? Like, you know, you know, like, what is your reasoning on, like, you know, what is something worth, like, implementing custom versus, like, just adopt it in the framework?

Uncle Bob Martin [00:28:20]:
Well, a lot of it for me, a lot of it is, control. How much control do I have over the parts of my system? And if I if I surrender to a database plug in of some kind, like MySQL or something else, I lose control over that. That's now under somebody else's control, and I'm I am a, I don't want to say I'm a slave, but I'm I am, subject to the whims of whatever they do, and that bothers me. So I want to I want to put a little isolation in there. Now I'm not gonna rewrite a compiler. I don't need a new language. I trust that the language is not going to do stupid things, and that's not always a good trust. I mean, I left c plus plus, you know, and, I left Java eventually too because they, you know, standards committees as soon as a language gets into a standards committee, I think the, the end is in sight, because they're just gonna keep on going and going and going and adding more and more deluged crap into the language and at some point you have to get a simple language.

Uncle Bob Martin [00:29:31]:
But for the, like, for fitness example, going back to the fitness example, we chose Java as language because it was kind of the obvious choice in the day. And it is it's still all written in Java and it's fine. Everybody's happy with it. Okay. Great. I'm not gonna do another big project in Java now because, you know, it's it's way out of control at this point. So I I look at that and think, I wanna keep control over as much of this system as I can and relinquish as little control as possible. And I can do that by trusting the vendors that I get, like the Java language, and then building isolation barriers to all of the things I don't trust.

Uncle Bob Martin [00:30:17]:
Interesting. I don't know if that answered your question.

Charles Max Wood [00:30:22]:
I I guess so. I guess I'm my my concern with, like, anything custom is maintenance cost. Right? Like Yeah. And so, like, that's the first thing I think about anytime I create something new that isn't, like, just some standard thing that most people know. Right. And so I'll, like One of the

Uncle Bob Martin [00:30:42]:
big things that happened to to us with fitness was that the the amount of code that we had to invest in these things that you would normally do with a framework was minimal, and the maintenance costs were almost nonexistent. We didn't need and in the end, we didn't need a relational database. We didn't know that upfront. Upfront, we thought we would need 1. In the end, we didn't need 1. And what does it take to take a hash table and dump it out to flat files? It's, you know, not a lot of code. We didn't need a web server because we put one together, 300 lines of code. It's not a lot of lot to maintain there.

Uncle Bob Martin [00:31:20]:
So one of the things that I found is that if I'm careful about making these these framework like decisions, I may be able to replace the bulk of a framework with something much simpler that's easier to maintain than the framework is. So I'm I'm just trying to think here

Valentino Stoll [00:31:45]:
then because, you know, somebody could listen to this and be forgiven for thinking, oh, so Bob's advocating that maybe we don't use frameworks.

Uncle Bob Martin [00:31:55]:
Yeah. No. That's not what I'm advocating.

Valentino Stoll [00:31:57]:
Right. So so my question then is, okay, so at what point do you consider adopting a framework? Because as you said before, a lot of times, people go in and it's like, I need a new web thingy that does whatever it is that I need done, and we use Rails for everything else here. So we're just gonna stamp Rails on it and go. And you're advocating for maybe a more measured approach where you solve some of the other problems first.

Uncle Bob Martin [00:32:28]:
Yeah.

Valentino Stoll [00:32:29]:
So at what point in this life cycle do I go, oh, well, maybe, you know, maybe I do need a framework or maybe I don't need a framework.

Uncle Bob Martin [00:32:39]:
There's several several decision points there. Right? 1st so number 1 is you've maybe you've got a little bit of an application going. You haven't invested in a framework yet. You've got a few business rules cooking. And then you think, alright. You know, I need something to help me with x, whatever x is. Might be putting things in the database, might be getting things on the screen, might be pushing things out to a service, whatever x is. I need help with this x thing.

Uncle Bob Martin [00:33:06]:
And you've the first thing I would do is look at, well, how hard is this x thing to do myself? And if it's easy enough to do myself, you know, like writing a hash table out to a to a flat file, well, I'm gonna do that first. Now my my, my supposition there is that that won't last, and that by the way, that's the way we felt about the fitness decision. We thought that the writing it out to a flat file was a stop gap. We we thought we would still go to a relational database. We just never did. So that's the first thing is I would I would see, okay. Is there some way I can get close to this x thing that I need by doing something myself, something simple, something really stupidly simple, and that'll that'll give me more time. And I might have to go to a framework to solve x or maybe not.

Uncle Bob Martin [00:33:57]:
Now at some point, you think, okay. I I gotta get to the framework. I did this recently with another application I was working on. I was I was trying to stay away from a GUI framework and and I didn't want to do it. I didn't want and then in the end, I thought, okay. I just can't deal with all the all the little editing fields and the double clicking and the cursor blinking and all that stuff. I don't wanna have to write all that code myself. I'm just gonna have to use a GUI framework, and, unfortunately, I picked the wrong one.

Uncle Bob Martin [00:34:27]:
I picked swing, and so so now I'm in a pickle to get rid of swing, tear it out of there, and replace it with something else. But you do eventually, you face that. Right? That there's this point where x you you can't do x yourself, so now you've got 2 options. You know you're going to have to use a framework. Do you commit to the framework and live with it forever or do you isolate yourself from the framework? The mistake I made with swing is that I did not properly isolate myself from swing because swing is not an isolatable framework. If you use swing, you have to commit to it. And so I committed to it and now now I'm in a pickle. I've got to dump it and throw it away.

Uncle Bob Martin [00:35:13]:
But sometimes you can take a step into a framework, but keep it isolated enough so that you can feel it out and defer the defer the commitment. Use it, but defer the commitment for a while. And you may find that that's sufficient or you may, in the end, just say, no. There's no way I can do this without making a commitment, and I understand the cost and the risk of making the commitment, but it's worth it. And that's that's the chain of decision making that I wish people would make. What I see people do is say, man, we got this new application to do. Let's fire up rails. Guilty.

Uncle Bob Martin [00:36:00]:
Okay.

Valentino Stoll [00:36:00]:
I do that. Maybe

Uncle Bob Martin [00:36:02]:
maybe that's not the first decision to make.

Charles Max Wood [00:36:09]:
Yeah. I mean, speaking of this, though, like, it's hard so the whole, like, premise of, like, DHH and the one person framework and rails is, like, the core principle is, you know, as he states, conceptual compression. Right? Like, basically, hiding away all the details that most people won't have to know so they don't have to know it. And so, like because I know, like, especially as you're early on coding, even middle, right, like, it's hard to create abstractions. Right? Like, it's hard to choose the right naming, choose the right communication layers. Right? And so, like, these are very hard, like, design problems and and challenges that most people will face, and it and it's easy to make a mess. Right? Like, if you start especially if you start from nothing. Right? Like, you could very easily okay.

Charles Max Wood [00:37:01]:
I'm just gonna make like, I'm gonna start with just, like, a command line application, and it's one script that has 5 lines, and it's just gonna, like, output standard out. Right? And, like, that's the application. And, like, next thing you know, you have, like, you know, a 1,000 lines of code that's all, like, you know, entangled and, like you know, it's very easy to to blow things up. And so, like, where, like, at what point do you, like, where where do you, like, recommend people, like, to look for, like, building better abstractions and, like, how to, like, make these design choices? Like, it's you know, you don't wanna end up basically, like, designing up front too much too. Right? Like, how how do you find that balance?

Uncle Bob Martin [00:37:49]:
Well, I've been writing code for, you know, well over 50 years. So for me, the creation of abstraction

Valentino Stoll [00:37:55]:
I think he just said he's been coding longer than we've been breathing, Valentino.

Charles Max Wood [00:38:00]:
Collectively.

Valentino Stoll [00:38:03]:
Not not collectively. I told you I'm 45. But

Uncle Bob Martin [00:38:08]:
Yeah. Well so, you know, make creating abstractions for me is a relatively simple thing. I can envision the system in my in my mind and see where all the pieces are and figure out the abstract. It's not very difficult for me. I can imagine, however, that people who are much newer to programming find that to be something of a challenge. I remember that I certainly did when I was in my twenties. Right? You know, made a lot of mistakes. And how do you deal with that? You get some old people on your team

Valentino Stoll [00:38:37]:
is what you do.

Uncle Bob Martin [00:38:39]:
You get you get some you get some guys who know what they're doing, and you have them be the team leaders, and you, you know, and and, you know, they can be the foreman, and they can say, okay, guys. You know, we don't need to rush. Yes. The framework is fancy, and it's very nice, but let's try this one little thing first. See if we can see if we can

Charles Max Wood [00:39:01]:
move slowly and Any wisdom you can impart here on, like, maybe, like, what your thinking is when you're, like, trying to like, let let's say, like, you have a task at hand that you you know, you have this problem you're trying to solve. Like, what's the first thing you start to do to maybe tease out what the abstractions are and how to model things? So there's a

Uncle Bob Martin [00:39:25]:
a frame of mind that I like to put myself into, which is to find the underlying abstraction. And and to find the underlying abstraction, you have to divorce the whole problem from detail. So you have to enumerate all the details. Now the details are all enumerated in the requirements. When you get a bunch of requirements, what you are getting is a load of details because that's what all the marketing people and all the business people. They're all writing down the details. And you have to look at this and you have to go, okay. All these details are driving at something else, something core.

Uncle Bob Martin [00:40:07]:
And so you 1 by 1, you subtract out the details and you envision where this thing is actually trying to go. So they, you know, they they'll give you, a whole bunch of, wireframes. And the supposition, of course, is that this is gonna be on a screen and it's probably on the web and they've got, you know, webby like buttons and they've got webby like scroll bars and and and dialogue boxes that would come up on a web, and and the requirements just look like it's web. And then you you'd say, okay. Get rid of all these details. What is really going on in here? Bit by bit, you rip away the details 1 by 1, and then you stare at what's left over. And if you can if you can describe the purpose of the application without using any of the detail words, like, you know, the web page or the dialogue box or the button or clicking or dragging, if you can enumerate if you can say what this application does without mentioning any of those details, then you are close to the underlying abstraction. And then at that point, you can start building back up.

Uncle Bob Martin [00:41:17]:
So, okay. Now I get it. Now I know what this application is actually doing. I know the core loop. I know what the steps are inside, and now I can start to build it. And, you know, maybe it shouldn't go on a web page. You know, maybe it should go on something else, and maybe maybe we shouldn't store the data in in, Oracle. Maybe maybe it should go somewhere else.

Uncle Bob Martin [00:41:48]:
You know? May maybe this core idea is better implemented with a different set of details, but you can't get there until you until you've gotten rid of all those details. And that that that just takes will and effort, right, to just stare at the problem and reduce it down to the barest bones and then then re then re, reinflate it, but reinflate it in in a direction that is better for everybody. Yeah.

Valentino Stoll [00:42:23]:
Well, it's it's interesting too because I think you also, one thing well, you you kinda said it when you started, but, it's like when I'm helping my kids with their math homework, you know, Valentino asked, well, how do how do you tease out those abstractions? And you said, well, I've been programming for 50 years. And, you know, I help my kids with their math problems. Right? I'll look at it and I'll say that's wrong. Right? And they're like, well, how did you how did you figure that out so fast? Well, I've been doing math for a really long time, and I've done it lots and lots of times. And so I I think I think a lot of this is also just getting in and solving these kinds of problems and doing a whole bunch of this dirty work and figuring out, oh, okay. When I see this, it means this. You know, you know, you start doing some of that mental pattern matching because you've you've done it so many times. Right? And and so I think there's a lot there.

Valentino Stoll [00:43:19]:
But, yeah, I I love the approach that you outlined because, yeah, a lot of times, it it is. It's just down to grit and, you know, moving away from those abstractions. Now I have to say that a lot of so the you know, that you get the wireframe and all that stuff. See, I need you to come and explain to the clients that I often work with that the application is not the wireframe. Because I'll tell you, when I show up to a stand up meeting or a demo meeting, they want to see all of the stuff that you told me to ignore. Yep. And so how do you balance this?

Uncle Bob Martin [00:43:57]:
Right? How do

Valentino Stoll [00:43:58]:
you balance out the okay. This is an app that does x, y, and z. Right? Like, right now, I'm working on an app that tracks transactions and does a whole bunch of math for hedge funds. Right? At at its core. Right? But if they don't see the stuff on the screen, then they aren't happy people. And so how do you balance that out?

Uncle Bob Martin [00:44:23]:
Well

Valentino Stoll [00:44:26]:
Right? Because they want the rails stuff. The right? All that stuff that I got from my framework. They want it. Now.

Uncle Bob Martin [00:44:34]:
Well, but yeah. They think they want it because that's how they envision it. Right. Right? They they have a vision of it, and they're envisioning it that way, which is fine. And and one of the ways you one of the ways you can do that is to, give them glimpses. So, for example, one of the things that we did long, long ago is we used fitness. Fitness is a, an acceptance testing frame. Right? So you you enter data into tables and it it'll send that data into the your application, and then it will compare that with the results that are in the table as well and see if you you pass or fail.

Uncle Bob Martin [00:45:13]:
So you pose a test as a a set of table data. And what's interesting about that is that since it's a Wiki, you can change the data in the table. So a very nice thing to do for marketing people and users is to give them an interface like that where all the calculations are being done. And then you give them a simple interface, something like fitness or something else, doesn't really matter, and let them fiddle. And they could see the the they can see the actual business rules executing, which is really what they want to see. Mhmm. They want to see the business rules executing. Right? They understand that if the form is a little different, it doesn't matter.

Uncle Bob Martin [00:45:55]:
They want to see the business rules executing. They gave you wireframes because they thought that was the best way. They also have another viewpoint, which is the customer outward looking viewpoint. They think that these wireframes are the best way to communicate with the customer. Fine. Fine. Fine. But let's make sure that we're doing the calculations correctly first.

Uncle Bob Martin [00:46:14]:
And, oh, let we'll just put it up on some dumb little thing. We don't have to invest in a horrible framework. We can just toss it up and look at it, and you can fiddle with it and play with it and see if we're doing that part right. Because let's get that part right first, and then we can figure out how to get it up on the screen with all the drag and drop gooey stuff and maybe, you know, maybe by then your ideas will change about how that ought to look to the customer. One of the things about details is the details are the things that change. The core business rules don't, but they don't very much. But all those core deed all those details, all those things that are on the wireframes, all those things that are in the requirements, they are the things that change the most frequently. So you want to kind of get them outside of the of the core so the core can remain safe from the volatility out here.

Valentino Stoll [00:47:08]:
Right. This kinda reminds me of the talk. I'll have to go find it,

Uncle Bob Martin [00:47:12]:
but it

Valentino Stoll [00:47:13]:
was I think it was Gary Bernhardt that talked about having the, he talked about having the core of his app, and then he had all the Yep. And and I think somebody else talked about some of the similar ideas with, like, hexagonal architecture and

Charles Max Wood [00:47:26]:
things like that.

Uncle Bob Martin [00:47:26]:
Yeah. It's all part of it. Yeah. All these architectures, they all have the same general idea. A hexagonal architecture, clean architecture,

Charles Max Wood [00:47:35]:
Yeah.

Uncle Bob Martin [00:47:36]:
Ports and adapters, all of them have the same basic idea. Right? Get the details out here because they're volatile. Get the business rules in here because they're not volatile. And the these are the family jewels here. You want those right. Everything else I have here, why don't you can fiddle with that?

Charles Max Wood [00:47:51]:
Yeah. So I wanna quickly talk about, framework speed. Right? Like, one of the biggest selling points of using a framework is just, like, speed of development. Right?

Uncle Bob Martin [00:48:04]:
Mhmm.

Charles Max Wood [00:48:04]:
Because you have all these normalizations. Everybody's familiar with all the things, and you can tie into all the framework things that they, you know, are they're opinionated. Just go with the opinions, and you can skip a lot of steps.

Uncle Bob Martin [00:48:16]:
Yep.

Charles Max Wood [00:48:16]:
So, like, how can we start to, like, simultaneously create the barriers without reducing that speed? Or, like, how can we keep up the speed at the same time? Like, at what point do you say I mean, obviously, for, like, the business rules, it makes sense to slow down because those are the most important. But, I mean, next to that, like, once you have those, like, isolated and resolved, like, at what points do you make those trade offs to slow down?

Uncle Bob Martin [00:48:45]:
Well, okay. You're you're saying you're saying something that I'm not quite sure is the premise is correct, like you like slowing down. So I don't think there's a problem with using a framework as long as you can touch it lightly. Right? So so let's say that, you've got some business rules and you think they're pretty good, and you want to get those up on a screen and you don't want to invest in writing your own screen stuff. So you think, okay. I'll I'll use this framework, but I'm going to use the framework lightly. I'm not going to dive in and do every fancy thing that that the framework is allowing me to do. I'm going to just get some dumb stuff on the screen without a lot of nonsense for the moment.

Uncle Bob Martin [00:49:29]:
Now that doesn't take you a lot of time. It's not going to stop you, it's not going to slow you down. Right? It's going to give you and your customers information that they can then use to take the next step. And at the next step, you think, well, that next step is is probably gonna make me do a bigger commitment to the framework. Is there some way I can isolate myself, or do I just have to decide to make the commitment to the framework and live with that commitment? Let me show let me show

Charles Max Wood [00:49:58]:
let me show you an example of, like, the of a slowdown from isolation. Right? Like, so let's say somebody has a task and they wanted to create a quick store. They didn't wanna use active record. They didn't wanna store in a database. That's clearly understandable. And, basically, what they've built starts to evolve in a more complex storage solution where it starts to be more complicated to understand as an example. Right? Like, let's say they're storing everything as a hash, and, you know, you have to, like, have multi dimensions in the hash to make sense of the data that's relational. And it starts to become more complex for other people to come in and understand it rather than just, like, a single person.

Charles Max Wood [00:50:38]:
So that's that's just, like, one small example of, like, a slowdown. Right? It's, like, creating some unfamiliar territory in an abstraction that at the time was maybe a good choice, but has evolved to something that now is more complicated. Like, I know for you, it's probably easy to see that, oh, like, this is becoming this is taking on too much at a certain point in your abstraction. Right? So how do you, like, how do you surface these things across your team? Right? Like, is it just, like, peer review is enough, or are there, like, planning steps that you take to prevent it?

Uncle Bob Martin [00:51:15]:
Well, peer review would would be a a good thing to do, especially if you've got some experienced people on the team. Better than peer review would be pair programming.

Charles Max Wood [00:51:23]:
Right?

Uncle Bob Martin [00:51:24]:
So if, if you've got an experienced guy and he sits down with a younger guy and the younger guy has been doing this this clever little data thing, you know, look, look, I didn't use the database, I did this instead. I'm I'm using name value pairs everywhere and it's just so cool. And the experienced guy sits down with that and says, yeah, that is pretty cool. Now let me tell you what bad thing is going to happen to you because you were doing that and let's see if we can construct an interface between what you've done and what the application is so that in the event that we need to get away from your clever little name value pairs, we can actually use a different structure. This is architect level stuff. Right? Some somebody who is they've got 10 years of experience, 15 years of experience, and they can look at what the what is going on and say, yeah. We need to protect ourselves and rearrange this a little bit. Most of the questions you fired at me are I I could rephrase as, how do I deal with the fact that everybody here is under 25? Okay.

Uncle Bob Martin [00:52:32]:
And you know there's just no good way to do that. It's it's important to have people on the team that are experienced enough to prevent the prevent the problems. Now one of the one of the problems with making the commitment just because at some point, you may have to decide. I'm gonna commit to this framework. I'm gonna live with that. But one of the things you need to be able to foresee when you make that commitment is just what kind of an impediment the framework is going to be. What things now that you've made the commitment, what things is it going to work against me at? What things will it prevent me from doing? And and that's a significant issue because as as applications grow and as they get more complicated, the initial help that the framework gives you will often turn into a drag. Something that slows you down as then now you've made the commitment, you're gonna be slow.

Uncle Bob Martin [00:53:36]:
And the more you want to do with it, the slower you're going to get because it's fighting you at every turn. The opinions of the framework are no longer the opinions of the application, but you're stuck with the opinions of the framework. So when you make that decision to commit, make sure you're looking ahead far enough so that it's like, okay. This application really is going to go in the direction of the framework for the next 5 years, and we're not gonna run into any of these impediments. That's a tough decision to make. Again, that takes somebody with a few years experience.

Valentino Stoll [00:54:17]:
Yeah. One one thing that's interesting because you're you're talking about this, and this kinda came to mind. I don't know if it makes the point perfectly, but it it illustrates it to a certain degree. So like I said, I'm working on this application that, you know, manages a hedge fund. And so when you import transactions into it from another system, you know, through a CSV or, you know, some third party API, it has to recalculate the, you know, the basically, the balance sheet for the the hedge fund. And, the at a certain point, they were using all the rails isms in the app, and it was super slow. It took forever to calculate all those calculations. Right? To to to work through all the transactions and, you know, because it had to tally stuff at each transaction.

Valentino Stoll [00:55:11]:
And so, I started looking at it and started working with it and realized that I could, do a lot of the work in the database. Right? So I was moving out of the framework. The problem that I ran into was that Rails, it does give you this nice interface to say, here's a SQL string, do stuff. But then I was in this world of I've got this really complicated SQL string that I've got to manage, and the framework didn't really help me with it at all. And then also figured out that a lot of the stuff I wanted to do was with just common table expressions, which is a feature in PostgreSQL, and that it had been brought into later versions of the framework. So now all of a sudden, if I want to use this version, I've got to I've got to update and I've got to adopt all the other things to get to the newer version. And so that's where some of this stuff came came to light for me. Right? And so there's all kinds of other stuff that I am doing super fast because I'm so familiar with Rails.

Valentino Stoll [00:56:15]:
Right? And I think, you know, just to just to point it out, we're not bagging on frameworks. We're just saying there are trade offs you have to make if you're gonna use them. And so in this case now, yeah, I'm I'm making another commitment to another version, and I have to take on everything else that comes with the new version of the framework. You guys are real quiet. Like, I either said something brilliant or dumb.

Uncle Bob Martin [00:56:37]:
You you stated an an undeniable truth. That does happen, and and I've seen that kind of thing happen more than one time where you get involved with a framework and it's great for the 1st 3 months, and then the next 3 months is like, and then the 3 months after that

Valentino Stoll [00:56:55]:
is like hell. Yeah.

Charles Max Wood [00:56:57]:
It's But

Valentino Stoll [00:56:57]:
but in this case, it's not in

Uncle Bob Martin [00:56:58]:
my way.

Valentino Stoll [00:56:59]:
It just doesn't offer what I need, and in order to get what I think I need, I've gotta make another commitment.

Uncle Bob Martin [00:57:06]:
Yes. Yeah. And rearrange a bunch of stuff. So then you've gotta solve 3 problems.

Valentino Stoll [00:57:11]:
To do with what I'm trying

Uncle Bob Martin [00:57:12]:
to get.

Charles Max Wood [00:57:13]:
Yeah. This brings up a great point about dependency management. Right? And, like, taking on new dependencies in general, like, obviously has to be weighed, but, like, I guess my biggest, thing that I still struggle with is how do you say something that you're trying to integrate and use just because you don't understand how it all works, and it's gonna take too much time to tease that apart. Right? Like, I don't build rockets. I'm not gonna buy a rocket engine and take it apart and, like, replace something. Right? Because it's gonna take too much time to learn all that stuff. Right?

Uncle Bob Martin [00:57:50]:
Yep. So

Charles Max Wood [00:57:51]:
and sometimes using a dependency gives affords you that, ability. Right? And it it's a great great tool to use. So, I guess what I'm getting at is, like, where do you how do you weigh those things, when you're trying to reason about the framework in that this framework is great to use because it solves these things that I don't, have time to reason about. Like, do you weigh that as part of your design choices, or do you try and just focus on where your limits are first and then circle back to the framework? Like, you know, where's the cutoff?

Uncle Bob Martin [00:58:31]:
Where's the cutoff? Well, obviously, this is a judgment call and and the judgment requires some experience. But, you know, if I'm going to embark upon a real simple app, and I know it's simple and I know it's not gonna be and it's not gonna grow over the years, it's just gonna be a nice simple little thing and there's a framework out there that just does that, I'm gonna use that framework. I'm gonna make a commitment to the framework. I'm gonna use it. And, okay. I'm I'm pretty sure that application is not gonna grow. I could get burned by that decision, but, it's not gonna grow. It's fine.

Uncle Bob Martin [00:59:04]:
And, you know, 9 times out of 10, that'll be the right choice. Then you've then you come up with another application. This application, the guys asking for this are serious. They're they're looking 10 years down the line, and they want they want some significant stuff done. And so then you think, okay. I could get the 1st year going and really easy with the framework, and then after that, there'd probably be hell to pay. That might be the right decision might be the right decision because you've got time to market issues and start up issues and stuff like that. But it might not be the right decision.

Uncle Bob Martin [00:59:43]:
It's worth thinking about that one. It's worth saying, okay. You know, maybe there's a shorter path to get to a a high value high value first release without making a commitment to something that is going to really hurt me a year or 2 down the line. Now, again, well, that's just all judgment call. But the the first thing you wanna do is make that judgment call. Put it in your head that you're going to make the judgment call, and then you're gonna have to live with it. The thing you don't wanna do is just say, yep. We're going to the framework.

Uncle Bob Martin [01:00:25]:
No thought. Just framework. That's what you don't want. Yeah. Make the decision.

Charles Max Wood [01:00:33]:
To follow that up, like, you know, are there things in frameworks that lead you there? Right? Like, are you looking at problems and being like, yeah. This framework would be perfect for this thing because of x. Right? Like, are there obvious draws to you for, you know, some frameworks for some purposes?

Uncle Bob Martin [01:00:52]:
Well, sure. I mean, the the the demo applications are often very evocative. So you look at the demos and and you think, oh, yeah. It's exactly what I wanna do, and I I don't think I'm ever gonna wanna do more than that. You know, why wouldn't I use the framework? Of course I'm gonna use the framework at that point. Once I've made you know, once I've been a little bit careful about it, I say, okay. A good thing to do with frameworks, you guys this doesn't apply to you guys, but a good thing to do with frameworks is just to get a framework and write a dumb amp, just so that you know, you know, how how easy or hard it is for that first puncture.

Charles Max Wood [01:01:34]:
And

Uncle Bob Martin [01:01:34]:
then then you can that'll help you make some decisions as well. You guys are long past that, but, some some people who are new and thinking, yeah, let's just get, you know, whip the doo framework out here, and it'll just be perfect. Write a couple of apps, little things, just throw away apps just so that you know.

Valentino Stoll [01:01:52]:
Yeah. I was gonna say, you know, essentially, the point that I think both of you are making is knowing that you're gonna have to make this judgment call at some point, right, whether or not to to pick up a framework or a particular framework. Yeah. You can take steps to say, what do I need to know in order to make the right decision? And so then it gets into, yeah, what do I need to know about the framework? What do I need to understand about my application and the problems I'm trying to solve? And then you can kind of get them to, you know, okay. I got this point of information and this point of information, and I still need a little bit more information here and right. So then you start getting closer to being able to make a decision one way or the other. And the decision may be not yet.

Uncle Bob Martin [01:02:39]:
Yeah. So Right.

Charles Max Wood [01:02:41]:
Yeah. You know, I was I was semi hopeful with all these new AI generator things. Like, as an example, Bolt dot new. Right? Like, you just say you give them all your the requirements, and then they that's like you know, can help get your demo app ready. Obviously, there are some dangers there long term vision wise Yeah.

Uncle Bob Martin [01:03:04]:
Yeah.

Charles Max Wood [01:03:04]:
As we've outlined here. You know, are are there any like, is there any path to, like, something in the middle there that can help you get and gather the requirements to the more modular steps that you need to take rather than all at once kind of thing?

Uncle Bob Martin [01:03:24]:
So the application that I've I've been working on for the last couple of years is a, it's a a browser for a social network. And I I started on this and I thought, okay. I I really don't wanna get a GUI framework in here. So I I found some dumb little thing. Helps me do graphics on the screen. It's really low level, you know, like, I can put a dot here. I can put a character there. It doesn't have any dialogue boxes or editing or anything like this.

Uncle Bob Martin [01:03:57]:
It's really bare bones. And I started using that. And, you know, I was able to get some stuff on the screen, but the problems that I needed to solve were not getting things on the screen. The problems I needed to solve were all these web socket things. I had dozens of web sockets, and I had to be able to turn them on and turn them off. And I needed to be able to unpack and pack these packets, and there was all kinds of cryptography gunk going on. So I spent a lot of time on that. And then I could get, you know, a couple of words on the screen, and I thought, oh, this is really cool.

Uncle Bob Martin [01:04:27]:
You know, I'm actually receiving messages, and I can send messages. Now look at that. And and then then I needed to edit them. And, you know, editing stuff on the screen, that's a nightmare. I I did not want to write, you know, inside Macintosh again. I did not want to write the whole GUI framework. And that's when I chose Swing. I made this I made this decision, and it was the decision to commit, and I made it based on the fact that a lot of other apps had committed to Swing.

Uncle Bob Martin [01:05:00]:
Okay. It's probably okay. I can commit to Swing. I already had the guts of it. Right? I had all the WebSocket stuff and I had all the fancy decryption and all that stuff was going on. I just needed the bolt swing on, and I had a nice isolation barrier. And then, okay. I can probably slip this in.

Uncle Bob Martin [01:05:18]:
No. There's just no way. Swing is just so horribly opinionated. And I've I've fought through that for a year. Just made the wrong choice, wrong judgment call. K. I just can't go on with this application. I'm going to have to rip, swing out, and replace it with something better.

Uncle Bob Martin [01:05:35]:
And that's going to happen to all of us. You know? We are all going to make the wrong judgment call and find out about it a year later. That's just the way software is. And, okay, you've got to kind of look look at that with, clear eyes and and realize, okay. I'm gonna make this call, and I hope it works out. It might not. But don't make the call frivolously. Right.

Uncle Bob Martin [01:06:03]:
Right? So just use the amount of information you got. Solve there's an old saying, and it and it comes out of, god, where was it? I think it was The Moon is a Harsh Mistress. Do you ever read that book?

Charles Max Wood [01:06:17]:
That's a great book.

Uncle Bob Martin [01:06:19]:
Yeah, it's a great book. Let me tell you a little story about that one before but but in that book, there is a quote, and the quote is, when faced with something you don't understand, do any part of it you do understand, and then look at the overall problem again. Right? Which is just the basic incrementalism step. Right? Break it into increments, don't leap into the whole thing. Break it into increments. Solve little bits that you do understand or or that you have a chance of understanding, and then you can look outward a little bit, and it'll look different.

Charles Max Wood [01:07:06]:
Yeah. Great advice. Yep.

Valentino Stoll [01:07:09]:
Alright. Well, I'm gonna push us to pics.

Uncle Bob Martin [01:07:12]:
Yep. Okay. And

Valentino Stoll [01:07:13]:
this has been so good. Yeah. Valentino, do you wanna start us off?

Charles Max Wood [01:07:23]:
Sure. Yeah. All my picks today, I have some awesome coworkers, and they've been releasing some open source stuff. So I wanted to share what they've been working on because, it's pretty pretty fun stuff. The first one comes from, my coworker, Jordan. He created this gem called Reprise. It actually uses, Rust to make, performant, like, schedules. So, like, if you use a gem called ice cube or something like this, it lets you, like, define ranges and and have, like, a schedule object that can iterate over things really quickly.

Charles Max Wood [01:08:01]:
And he he built it using, like, a a Rust toolkit that snaps in to the, the Ruby subsystem, called Magnus, which is pretty sweet to solve this specific problem. It's a really cool gem. The other one is, my coworker David. He created this, this repo a long time ago called Octo. That's like a a knowledge management app that you run locally on your system. And it's just, like, really fully featured. It has n n encryption support and, it's cross platform and has all kinds of crazy support in there. And you could think of it kind of like Obsidian or something like that, but fully open source.

Charles Max Wood [01:08:49]:
And the the last one is, something I haven't gotten to play with yet, but my coworker, Robbie, created this thing called Cambium, and it's a a basically, a a way to configure Kamal and set it up, really easily on, Ubuntu and Deviant systems. So it's like a configuration tool for Kamal to just make it easy. So that's, that's really neat as well.

Valentino Stoll [01:09:20]:
Awesome. Alright. I'm gonna jump into mine. Some of those I'm gonna go try out, by the way. It's like, oh, I'm working on that. So the first one I'm gonna pick, I always do a board game. The one that I've been playing with my friends lately is Heat, and it's a racing game. So, your marker on the board is a race car.

Valentino Stoll [01:09:45]:
The car goes around the track. At different points, you, get to a curve. And if you take the curve too fast right? So if it's like a a 2 curve. And the way you move is you you put down cards face down. Everybody does this at the same time. And then you just go from the front of the pack to the back, and everybody flips their cards over and then moves however many, they put down. And and there are some factors in it that'll make you go faster or slower. Right? You can put one down that you flip cards until you get, you know, a card with the mark on it, and then you go that many.

Valentino Stoll [01:10:27]:
So if you go around the curve too fast, then you take on that much heat. So if it's a 2 curve and you go 6, you take on 4 heat. If you run out of heat in your engine, then you spin out and, you basically have to go back to the curve and take the curve at a at a decent speed. And at that point, you can't go over because you're you're out of e heat in your engine. There are ways to cool off, a lot of catch up mechanisms that made it a lot of fun. But yeah. I mean, that's that's essentially the the crux of the game. Right? You can you can draft and then pass other cars.

Valentino Stoll [01:11:05]:
You can, I mean, there there are other rules, and there are, like, 4 or 5 racetracks or game boards that come in the in the game? It's really, really fun. BoardGameGeek weights it at 2.19, which is, you know, it it has enough going on to be interesting, but a casual gamer wouldn't, you know, play it and then say, this is way too complicated. So, I'm gonna pick that. I'm gonna put the links to it, the board game geek, and then Amazon links into the the chat here. And then I've got a couple of books that I read. I actually listened to them on Audible. One of them is Hit Refresh by Satya Nadella. Satya is the CEO of Microsoft, And he basically so the book is a little bit I don't wanna say it's, like, dated, but it, you know, it's not up to, like, 2024.

Valentino Stoll [01:12:07]:
And so it it ends, you know, in the, late 20 teens, you know, maybe around 2020. And so, he talks about, basically him taking over Microsoft and then kinda leading it into this new age, with cloud and stuff like that and, talks about his background and stuff like that. It is it is really, really good. I really enjoyed it. The other one that I listened to, and this is also a company kind of takeover turnaround book, is American Icon by Bryce Hoffman, and this one is the turnaround of Ford Motor Company. And, Bryce Hoffman so hit refresh is an autobiography ish. Satya is the the primary author. American Icon, he's an industry, what, journalist, I guess.

Valentino Stoll [01:13:02]:
And so he got a lot of the inside track from a lot of the people in Ford and then wrote the book. And, anyway, it was it was really fascinating just to listen through, oh, this is how we solve this, and this is how we solve that. You know, it it goes through the the recession in 2 2008 and, you know, some of the deals they were trying to work out with the government, which I I'll admit I don't love, corporate welfare from the government, but it was interesting to see the approaches and how they dealt with people and how they did all this stuff. So, I'm gonna pick that. And then lastly, I think I might have mentioned a few times that I am running on Ubuntu now. I bought a a desktop. The place I got to so my laptop, when I'd run Docker and run the stuff for any of my clients, my laptop would just slow me down. And I was starting to get into AI, and that would slow it way down too.

Valentino Stoll [01:13:57]:
And so, I decided I needed a a newer machine, and so I started looking within the Mac ecosystem, Decided pretty quickly that what I needed was not a laptop. And so I looked at the Mac Pro, and it was, like, $12 for the one that I was thinking I wanted. And I was like, that that was a tough pill to swallow, especially since my, income's kind of been up and down this year. But I I was slow getting my client work done because I'd have to wait for it to run all the tests and stuff, and it'll take forever. So I looked around, and DHH was recommending the framework, laptop, and I thought, oh, that looks nice. But, again, I had decided that the laptop was probably not gonna give me the horsepower I wanted. And so they the folks on there, and I don't know if he recommended it or somebody else did, but, they were all talking about a computer company called System 70 6. And so I ordered from them.

Valentino Stoll [01:14:58]:
It did take a bit of time because they custom build the the desktop and then send it to you. But this this one cost me, like, $33100 instead of $12,000. And so that's what I am running on right now, and it's been terrific. I've had to adjust to running on Linux instead of on Mac, but I've been pretty happy with it. I know other people do work on Windows. I just

Uncle Bob Martin [01:15:30]:
I I don't know.

Valentino Stoll [01:15:31]:
I've kind of gotten I I let me put it this way. So, my wife, my mother-in-law, and everybody else, right, that's not a tech person that I know runs on Windows, and it I just get tired of the maintenance hassle that I run into on Windows. And the other thing is is that you have to run it through, you know, all the stuff that I do. I typically wind up running through the Linux emulator system that they have built into Windows, which works okay. Right? I I don't hate it. But it was just like or I could just run everything on Linux because that's how I'm running my life anyway. Right? I mean, all my code deploys to Linux. And so, yeah, I've been I've been very, very happy with it.

Valentino Stoll [01:16:17]:
It does essentially everything that I want it to. The only things I run into that it can't do is you'll notice that I have the green screen setup behind me. If I want to run the green screen, I kind of have finagled things so that I can run the management software for the, video mixer on wine, but it still doesn't quite work the same as it does on the Mac. So I may just wind up doing all my streaming and recording on my Mac. And then because I still have my MacBook Pro, but I just I won't run out all the other heavy duty stuff. And then, if I get in a pinch, GIMP and stuff work fine for the image editing and stuff, but, you know, I I have the Adobe tools on my MacBook Pro, and so I'll run that there too. But, I mean, everything else, it's just been and and it's such a terrific dev environment. I just I can't say enough good things.

Valentino Stoll [01:17:17]:
So system 76 is my last pick. Bob, do you have some picks for us?

Uncle Bob Martin [01:17:22]:
Well, I thought I'd I'd, jump into some science fiction books since that's my genre. And we had talked about the moon is a harsh mistress. There is an alternate reality version of that story, And then and the the name of the book is, the powers of the earth, and it's written by Travis Corcoran, if I remember correctly. And it's absolutely hysterical and and dead serious at the same time. It's it is, it is the story of the moon is a harsh mistress, but told in a, a very modern, meaning current day, political environment. So very funny in a number of ways and, very serious in another bunch of ways. So that's one book, worth the read. There's a there's actually 2 books in the serious plus a bunch of short stories, all of them worth reading.

Uncle Bob Martin [01:18:27]:
Travis is a software developer, so there's tons of Easter eggs. You know? If you're a programmer, tons of Easter eggs in there, and, I think he's off in the northeast somewhere living on a on a farm or something now. Some some programmers do that. Another book that's, book series that I found great, this goes back about 5, 6 years, is the whole Babaverse series, by Dennis e Taylor, I think it is. And this is again, it's the story of a software developer, and I think I think Dennis Taylor is a software developer too. And it's the story of a software developer named Bob who, sells his company, makes a fortune, and the first thing he decides to do is, sign a contract so that his head will be frozen in the case he dies, and he'll be reawakened in some future time. And he walks out of that after signing the contract, he walks out of the door and gets hit by a car, and he wakes up as the brain of a spaceship. After that, everything gets very interesting.

Uncle Bob Martin [01:19:32]:
It's a great story, and it goes on for several several books, some of which are just hysterical, and they're all very funny and ironic and and, marginally plausible. So that's a cool book. Marginally plausible. Marginally plausible Yeah. Okay. And then the last one is a new one, and the, the author's name is I can't remember. The name of the book is Theft of Fire. And this this book, I have been oh, Devon Devon Erickson.

Uncle Bob Martin [01:20:10]:
Devon Erickson is the author. I've been a hard sci fi guy for a long time, and I've been very disappointed with the late genre of sci fi because there's not a lot of good hard sci fi. If you, you know Mhmm. You know, Mars was a great story. Okay. Yeah. The Martian. Yeah.

Uncle Bob Martin [01:20:30]:
The Martian. We're writes good stuff. But, there's been a lot of kind of fluffy sci fi. This one is great. It's just great. Good good hard sci fi, a great premise, great characters, so I'm I'm very, very excited about this book. I read the first, and he's supposedly in the midst of writing the second one, so I'm dying to get my hand on that, Theft of Fire by Devon Erickson. So my hope is that there's a rebirth in the hard sci fi genre.

Valentino Stoll [01:21:05]:
Nice. Alright. Well, I am also just gonna plug your book, We Programmers. It's on Amazon. You can go buy it right now. Yes.

Uncle Bob Martin [01:21:14]:
It is.

Valentino Stoll [01:21:15]:
And, yeah. I look forward to CleanCoaters 2nd edition. Alright. Well, thanks, Bob.