Evaluating Software Frameworks: Insights with Uncle Bob Martin - RUBY 666 - Ruby Rogues

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:04):
Hey, Welcome back to another episode of the Ruby Rogues podcast.
This week, on our panel, we have Valentino Stole.

Speaker 2 (00:11):
Hey.

Speaker 1 (00:12):
Now, I'm Charles Maxwood from Top End Devs. I just
wanted to do a quick call out AIDEV boot camp
dot com. If you sign up within the next few weeks,
I'm doing a forty five percent discount because I turned
forty five on Saturday. And yeah, Bob's laughing. I'm going

(00:32):
to take a little personal license here. So there's a
political party I'm in county leadership, and we were talking
about youth outreach and our party secretary is probably pretty
close to Bob's age, and so we were chatting and
we had like this twenty two to twenty three year
old young woman who was talking to us about reaching
out to younger people. And somebody goes, so, when we're

(00:56):
talking about youth, who are we talking about? And he
chimes in, and he goes and buddy under forty five.
And so I felt young for like a week and
a half and then I turned forty five. So anyway, Bill,
now that's right, I'm old now. So anyway, we also
have Uncle Bob Martin or Robert C. Martin as people

(01:16):
know him. Bob, do you want to just say hello
and let people know what you're up to these days?

Speaker 3 (01:20):
Hi? Yeah, what am I up to in 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 sixteen seventeen years. Yeah, So first draft
is off to the publisher. They're going to send it

(01:42):
out for review, then we'll do another scan through it,
and I imagine we'll see it out mid next year.

Speaker 1 (01:49):
Good deal. You also released and this came up on
the JavaScript Jabber Show and I was excited for it,
and so we're definitely going to have you back on
this show and that show to talk about it. But
you released another book about historical programmers.

Speaker 3 (02:05):
We Programmers is the title of it. The publisher taught
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 history of

(02:28):
software programmers, starting with Babbage and then walking through the
early twentieth century, early to mid twentieth century. So we
get people like Dykestra and Hilbert and von Neuman and
Touring and Grace Hopper and John Bacchus and of course

(02:50):
the C Trio Dennis Ritchie and Ken Thompson and Brian Cernihan.
And I focus on the technology. This is a book
for programmers, So I talk about 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,

(03:13):
how much memory did they have, what kind of memory
it was.

Speaker 4 (03:17):
And I also focus a lot on the the personalities
of the programmers, specifically their life struggles, because all of
these people.

Speaker 3 (03:27):
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 attract the attention of programmers. So that's that's how

(03:52):
the book goes.

Speaker 1 (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 difference, I guess is that 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

(04:15):
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.

Speaker 3 (04:28):
So it's easy to draw a line if you look
at the technologies, and if you really dig into the technologies,
it's easy to draw a line from there to hear right,
And that line is this exponential curve which we called
Moore's law back before Moore's law died. But it's very

(04:49):
interesting to you look at the earlier mechanical machines, and
then the electro mechanical machines, and then the vacuum tube machines,
and then the transition machines, then the integrated circuit machines,
and 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

(05:12):
waves through tubes of mercury, and then it was charged
dots on CRT screens, and then then finally it was
core memory, real core, magnetic core, and then finally you
know discs and solid state memory. So very very interesting
and if you if you follow the deeper technology, you

(05:33):
can see that thread really easy, and you can see
the struggles of the hardware architects. They had no idea
what programmers would needs. So the early machines had no
way to call a subroutine, no way to store a
return address, no way to uh anything on a stack. Right,
the earliest machines had no jump instructions. They were just linear,

(05:56):
linear steps and if you wanted to, if you want
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. Oh no way, yeah, yeah yeah, And
the operators would have to check the registers to see
whether or not the loop exit condition had been achieved.

(06:19):
But you know, when you're only executting ten instructions a second,
you can do that, and you know a good program
will run for eighty hours with constant operator intervention.

Speaker 1 (06:34):
Well, I have to say, I'm living a charmed life.

Speaker 3 (06:40):
Yeah. Here we are communicating over the ancestors of these machines,
you know, whipping bits around at a rather impressive rate.

Speaker 1 (06:50):
Yeah, that's amazing.

Speaker 3 (06:53):
Yes it is. Oh yes, exponential curves. Yeah, we have
an effect over time.

Speaker 1 (07:04):
Yeah. Yeah, anyway, it's great stuff. I actually invited you
to come on and talk about and it's this snippet.
It's like, what three minutes, but it was it was interesting. Oh,
tarras on on X says, so that's where you rolling

(07:28):
your own loop comes from.

Speaker 3 (07:29):
Yes, they actually didn't do that. They would put the
paper tape into a loop. They'd scotch tape it together.

Speaker 1 (07:37):
Yeah.

Speaker 3 (07:38):
Yeah, except one time they twisted it and then it
was a mebias strip didn't execute.

Speaker 1 (07:42):
Well m m, all right, well let's dive in you.
So this is this video. I don't know if you
posted it or if somebody clipped it from a talk
you gave, but.

Speaker 3 (07:54):
It's essentially from a talk. Yeah.

Speaker 1 (07:56):
Yeah, so music in the images that show up, and
there's a guy that's massaging his temples.

Speaker 4 (08:06):
Right.

Speaker 1 (08:08):
Anyway, it's the problem with frameworks and 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 sidebarred

(08:31):
into react and view and you know, and all the
stuff there and trade offs with maybe he's Veldt or
something like that, and 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.

(08:53):
And so I was kind of curious to see if
we would have the same conversation here or if it
be a bit different just from the standpoint. But uh,
you know, you know, you know, just given the different technologies.
So I keeping that in mind, I just kind of
want to kind of let let you let it rip.

(09:14):
You know what, what are the problems with frameworks, right?
We all love ours.

Speaker 3 (09:18):
It was Rails that actually put me on this track, Okay,
because I had been 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 six or
something like that.

Speaker 1 (09:34):
Yeah, about then that's when I got into it.

Speaker 3 (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, ryls rails. I'm

(09:56):
using Rails. And I thought, well, that's odd. Why is
his directory structure so damned opinionated? And well, I mean
that's because Rails is an opinionated frame, right, And that
made me think, well, okay, should it be, or rather,
should I allow Rails's opinionation to influence the structure of

(10:21):
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 frameworks.

(10:43):
And as I was thinking about that, I thought, well, okay,
David is the author of Rails. David Hademeier Hansen, and
he did it for his company. He did it for
thirty seven signals, right, he did all that for him.
He didn't do it for me. And the more I
thought about it, the more I thought, you know, the
more I commit to Rails, the more asymmetric this relationship becomes,

(11:09):
because David is not making any commitment to me at all.
He's not promising to maintain Rails in the direction I
wanted to go. He's not promising to give me any
features that I want. He's going to 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,

(11:31):
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 androm.
The second one started with why. And so I thought, yeah,
I probably don't want to make a big commitment to
an author who has no commitment to me. I don't

(11:52):
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 uh In the opinionated structure
that he is properly creating for himself.

Speaker 1 (12:13):
Yeah, it's it's interesting too. I'm just gonna kind of
pile onto this idea a bit like if you go
watch the last keynotes that that David gave at when
we say David is DHH folks for the people that
aren't following along.

Speaker 3 (12:30):
A guy, I hold him very high regard, by.

Speaker 1 (12:32):
The way, right, Yeah, I mean I've known David now
for several years, and so I call him David, and
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

(12:53):
to his talk, what he says is is, Hey, we're
introducing this new thing and here's the problem. It's solved
for us at base Camp, right, I mean, all every
single thing it's and we had this problem at base
camp and we solved it with this, and now you
can use it too, right. And granted a lot of
those are things that I want solved to and so

(13:14):
I'm perfectly happy to pick them up. But but yeah,
I mean the truth is is a lot of the
stuff that ends up in Rails is stuff 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 problem
that's can contributing to the framework. But the vast majority

(13:36):
of the stuff that he goes up and announces, he
basically says it, this solved this problem for us at
base Camp.

Speaker 3 (13:45):
Yeah, and that's great. It's 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 heerding from some
base class that they wrote, or without you know, forcing

(14:05):
my application to adopt the structure that they want.

Speaker 1 (14:10):
Yeah, Rails Magic, what do you think of Valentino.

Speaker 5 (14:17):
It's so it's hard because the structure of the application,
if you're a contractor, as an example, a consultant, having
that be the same for all of the applications that
you have to look at is such a huge benefit, right,
And having a lot of the things normalized, maybe not

(14:38):
everything that reels normalized, but like the normality 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

(14:59):
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. Uh even,
but that's the trade off, right, Like you make that

(15:21):
choice upfront, and it's your choice, right, So, 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,

(15:43):
Like where where do you start to see Okay, like, uh,
we have started to design our pieces of the application
separate from the framework, Like when does that start to
take off?

Speaker 4 (15:53):
Right?

Speaker 5 (15:53):
And where does where does that like really start to
fit in the most obvious Well.

Speaker 3 (15:57):
I think that the first question that it 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, whatever the framework dujuur is.

(16:20):
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 up front? Or should
you be thinking about? All right, we've got this application,
and this application has a bunch of requirements, and we're
going to need this kind of data storage, and we're
gonna need this kind of computational structure, and what framework

(16:42):
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.
It would also be nice if the framework would be

(17:04):
less demanding of commitment, like I'd like to use it
off on the side, I'd like call it a little
bit and 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

(17:25):
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.

Speaker 1 (17:42):
So yeah, and this is this is kind of where
you begin to lose me a little bit because 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 Rhoda or or or do you just start building
the other pieces of your you know, maybe you build
business logic, But I don't know, like, what's the approach

(18:07):
here then to putting it off? Because yeah, rails gives me,
like Valentino said, it kind of gives me a bookshelf
and tells me where to put my stuff. Yeah, and
it solves a bunch of stuff out of the gate.
And so yeah, but at the same time, I really,

(18:28):
you know, it sounds right, you know, especially you know,
I kind of grew up programming under agile development stuff, right,
And you'll never know as little now or as little
as you do now. Kind of thing, 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

(18:49):
what I want. But how do you do that? How
do you start putting the pieces together without the framework? Then?

Speaker 3 (18:56):
Well, so frameworks solve a particular problem. 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

(19:18):
application exists. There are business rules that don't have anything
to do with the framework. 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. So you can create the core of an application.
You can start with some business rules and you can

(19:41):
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 don't you don't
need to make a commitment to the screen or the database.
You can build a little isolation layer that allows you
to put things on a database, but without knowing what database.

(20:02):
It is just a bunch of interfaces that you implement later.
And there's some way to get things on the screen.
You don't know exactly how you're going to 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.

(20:22):
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 going
to help me with this? I really need to get
this on a web page. Maybe you haven't even thought

(20:44):
about a web page yet, right, I really need to
get this on a web page, and Rails is great
at doing that. 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 rails ecode
to my application. Maybe I can put it all behind
my isolation layer, and then I can call rails happily

(21:07):
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. And in
the last one, I told the story of Fitness, And

(21:28):
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. And we as
we planned the whole thing out, we thought, well, we're
going to 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 CANU project had a bunch of I think Apache

(21:49):
had some web servers back in two thousand when we
started this, and we thought, you know, maybe we'll get
a database, and we had we thought we'd get my sequel,
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.

(22:14):
Don't need you don't even need a web page for that.
If you don't need a web server for that, all
you need to do is look at the HTML. Uh.
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 from HTML from a
flat file or something. So that was very simple. And
at some point we thought, well, we've got to get

(22:34):
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. 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 three hundred lines of code.

(22:56):
It's not very hard to serve a web page. Just really,
all you're doing is opening up a socket and throwing
stuff out of 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 three hundred lines of code and
it puts up web babes. It's just fine. And we
kept on working on translating the markup. Eventually we needed

(23:18):
a database, and we thought, well, we could get my
sequel 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 you can make calls against the hash table that
looked like a database query. So we build a little
interface that looked like a database query and put a

(23:39):
hash table behind it, and kept on working and working,
and we got the whole dog On program up and
running old wiki and all of the stuff that it
was doing, with lots of extra stuff that we were
doing in fitness, and we didn't have a database, and
we had our own little tiny web server. And then
we thought, well, I mean, we got to get this

(23:59):
stuff on discs 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 my sequel for the persistence,
and we didn't use apatche for the web server, and
we put the whole dog On thing together. It's it's
in one jar file and just turned it loose, and

(24:23):
you know, people were using it and using it. I
think it's still got a fairly significant user base today
after twenty five years. So that that's a story of
how I like to build from the inside out and
feel my way towards the outside world.

Speaker 5 (24:42):
It's funny you mentioned it like that because I feel
like from a real developer standpoint is like backwards where
for sure, like 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

(25:04):
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 because almost like the framework
is so like, uh, you know, opinionated, you want to

(25:26):
make opinionated patterns, and so it does have like kind
of that translating effect. But I like you're you're thinking
of like boundaries for sure. I think like creating boundaries
is like super important from like an applicant, 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

(25:48):
gem called Packwork, you know, designed by Shopify, and if
you haven't heard, it's like, uh, you know, a way
of just like creating those boundaries in isolation within a
real system, right, So it's like something that was created
to snap into a Reels thing to isolate it from Reels,
which is just a little bit funny because we're doing
again working backwards and it's and it's super funny to

(26:11):
me because like you know, this all comes from like
every everything in Reels is built on Rack, which is
like honestly a really great design framework because it has
like at this bare minimum, it's just like you know,
individual modules that you can drop or not write, and
you can add and stack on however many you want,
and all those individual pieces like uh you know, mutator

(26:34):
or adjust the stack that it's in individually and in isolation.
It's 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 reels is terms supposed
to be modular, and a lot of ways it is

(26:58):
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.
And it's funny because like that was a common practice
you know, in the early days of like even group
on right, Like you would just like, oh, you have
your your rails stack like explicitly defined in your setup

(27:18):
and say, oh, yeah, I'm gonna use all of these
things all the time. And now it's just like, well,
we were just going to require reels and 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
disk and that works and that's fine. Like as like

(27:40):
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 what point where's the
diminishing return there?

Speaker 4 (27:54):
Right?

Speaker 5 (27:54):
Like where is it, Like, Okay, we built all these
custom things that people have to manage over time and
make sure our secure and and things like that, Like
where where do you stop? Like do you go down
and like build compiler code? Like you know, like, uh,
what is your reasoning on? Like you know, what is

(28:15):
something worth like implementing custom versus like just adopted in
the framework.

Speaker 3 (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
my sequel or something else, I lose control over that
and that's now under somebody else's control. And I'm I
am a I don't want to say I'm a slave,

(28:42):
but I'm I am a 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 going to 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,

(29:09):
and I left Java eventually too, because they you know,
standards committees. As soon as the language gets into a
standards committee, I think the end is in sight because
they're just going to 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.

(29:31):
But for the like for fitness example, going back to
the fitness example, we chose Java as the language because
it was kind of the obvious choice in the day.
And it's still all written in Java, and it's fine,
everybody's happy with it. Okay, great, I'm not going to
do another big project in Java because you know, it's

(29:52):
it's way out of control at this point. So I
look at that and think, I want to 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

(30:15):
the things I don't trust. Interesting, I don't know if
that answered your question.

Speaker 5 (30:22):
I guess, so, I guess I'm My concern with like
anything custom is maintenance costs, right, Like yeah, and so
like that's the first thing I think about any time
I create something new, that isn't like just some standard
thing that most people know, it's all like what.

Speaker 3 (30:42):
Yeah. I think that happened to us with Fitness was
that the amount of code that we had to invest
in these things that you would normally do with a
framework was minimal. I mean, the maintenance costs were almost
non existence. We didn't need and in the end, we
didn't need a relational database. We didn't know that upfront.

(31:05):
Upfront we thought we would need one. In the end
we didn't need one. And what does it take to
take a hashtable 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. Three hundred
lines of code, a lot of lot to maintain there.
So one of the things that I've found is that
if I'm careful about making these these framework like decisions,

(31:30):
I may be able to replace the bulk of a
framework with something much simpler that's easier to maintain than
the framework is.

Speaker 1 (31:41):
So I'm just trying to think here 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.

Speaker 3 (31:55):
Yeah, no, that's not what I'm advocating.

Speaker 1 (31:57):
Right, So my question then is, okay, so 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

(32:18):
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, yeah,
so 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.

Speaker 3 (32:39):
There's several several decision points there, right, First, so number
one 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,
all right, you know, I need something to help me
with X. Whatever XES might be putting things in the database,
might be getting things on the screen, might be pushing

(33:01):
things out to a service, whatever X is. I need
help with this X thing. And if 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 flat file, Well, I'm gonna do
that first. Now, my my, my supposition there is that

(33:24):
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 is a stopgap.
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 say, 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,

(33:49):
and that'll that'll give me more time, and I might
have to go to a framework to solve X or
maybe not. Now at some point you think, okay, I
gotta get to the framework. I did this recently with
another application I was working on. I was trying to
stay away from a gooey framework and I didn't want

(34:10):
to do it. I didn't want it. And then in
the end I thought, okay, I just can't deal with
all the little editing fields and the double clicking and
the cursor blinking and all that stuff. I don't want
to have to write all that code myself. I'm just
gonna have to use a guy framework, and unfortunately I
picked the wrong one. I picked Swing, and so now
I'm gonna pickle. I don't have to get rid of Swing,

(34:33):
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 can't do X yourself. So
now you've got two options. You know you're gonna have
to use a framework. Do you commit to the framework
and live with it forever, or do you isolate yourself

(34:54):
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. But sometimes

(35:15):
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 it
that's sufficient, or you may in the end just say
now there's no way I can do this without making

(35:36):
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, Okay,

(36:00):
I do that. Maybe maybe that's not the first decision
to make.

Speaker 5 (36:09):
Yeah, I mean speaking to this though, like it's hard.
So the whole like premise of like DAHG 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

(36:30):
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 challenges that most

(36:53):
people will face. And it's easy to make mess right
like if you start, especially if you start from nothing,
like you can very easily Okay, And I'm just gonna
make like I'm gonna start with just like a command
line application and it's one script and it has five lines,
and it's just gonna like I'll put standard out right
and like that's the application, and like next thing, you know,
you have, like you know, a thousand lines of code

(37:16):
that's all like you know, entangled, and like you know,
it's very easy 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 want to

(37:40):
end up basically like designing up front too much, too right,
Like how how do you find that balance?

Speaker 3 (37:49):
Well, I've been writing code for you know, well over
fifty years. So for me, the creation of abstractions, I
think he.

Speaker 1 (37:56):
Just said he's been coding longer than we've been breathing, Valentino,
not collectively. I told you I'm forty five.

Speaker 3 (38:06):
But yeah, well so you know, make creating abstractions for
me is a relatively simple thing. I can envision the
system in my mind and see where all the pieces
are and figure out the abstraction. 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

(38:27):
a challenge. I remember that I certainly did when I
was in my twenties, right that you know, made a
lot of mistakes. And how do you deal with that?
You get some old people on your team, is what
you do. You get some guys who know what they're doing,
and you have them be the team leaders, and you
you know, you know they can be the fore man

(38:48):
and they can say, okay, guys, you know we don't
need to ruge. Yes, the framework is fancy and it's
very nice, but let's try this one little thing first.
See if we can. Can you see if we can.

Speaker 6 (39:02):
Slowly and any wisdom you can impart here on like
maybe like what you're thinking is when you're like trying
to like, let's say, like you have a task at
hand that you know, you have this problem you're trying
to solve, Like what's the first.

Speaker 5 (39:16):
Thing you start to do to maybe tease out what
the abstractions are and how to model things.

Speaker 3 (39:21):
So there's a frame of mind that I like to
put myself into, which is to find the underlying abstraction,
and to find the underlying abstraction, you have to divorce
the whole problem from detail. So you have to enumerate

(39:42):
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, and

(40:07):
so one by one you subtract out the details and
you envision where this thing is actually trying to go.
So they you know, they'll give you a whole bunch
of wireframes and the supposition, of course, is that this
is going to 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 dialogue boxes

(40:30):
that would come up on a web and the requirements
just look like it's web And then you say, okay,
get rid of all these details. What is really going
on in here? Bit by bit, you rip away the
details one by one, and then you stare at what's
left over and if you can, if you can describe

(40:51):
the purpose of the application without using any of the detailed.

Speaker 2 (40:56):
Words the web page or the dialogue box, or the
button or clicking or dragging, if you can, if you
can say what this application does without mentioning any of
those details, then you are close to the underlying abstraction.

Speaker 3 (41:15):
And then at that point you can start building back up. 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

(41:35):
on a web page, maybe it should go on something else.
And maybe maybe we shouldn't store the data in Oracle.
Maybe maybe it should go somewhere else. You know, maybe
maybe this core idea is better implemented with a different
set of details. But you can't get there until until

(42:00):
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 then re reinflated, but reinflated in
a direction that is better for everybody.

Speaker 1 (42:22):
Yeah, well, it's it's interesting too, because I think you
also one thing, well you you kind of 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 you how do you tease out those abstractions?
And you said, well, I've been programming for fifty years,
and you know, I help my kids with their math problems. Right,

(42:46):
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 think I think
a lot of this is also just getting in solving
these kinds of problems and doing a whole bunch of
this dirty work and figuring out, oh, okay, when I

(43:07):
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. But yeah, I love
the approach that you outline, because yeah, a lot of
times it is it's just down to grit and you know,

(43:27):
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

(43:48):
stand up meeting or a demo meeting, they want to
see all of the stuff that you told me to ignore. Yeah,
and so how do you balance this, right? How do
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 its core. Right,

(44:12):
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?

Speaker 3 (44:23):
Well?

Speaker 1 (44:26):
Right, because they want the rails stuff that, right, all
that stuff that I got from my framework they want
it now.

Speaker 3 (44:34):
Well, yeah, they think they want it because that's how
they envision it, right, right. They have a vision of
it and they're envisioning it that way, which is fine.
And one of the ways you can 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

(44:58):
acceptance testing frame. So you enter data into tables and
it'll send that data into your application, and then it
will compare that with the results that are in the
table as well and see if you pass or fail.
So you pose a test as a set of table data.
And what's interesting about that is that since it's a wiki,

(45:20):
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

(45:41):
they can see the actual business rules executing, which is
really what they want to see. They want to see
the business rules executing, right. They understand that if the
form is a little different, it doesn't matter. 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.

(46:05):
They think that these wireframes are the best way to
communicate with the customer. Yes, fine, fine, but let's make
sure that we're doing the calculations correctly first, and oh, look,
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

(46:26):
that part right first, and then we can figure out
how to get it upon the screen with all the
dragon drop booy stuff, and maybe, you know, maybe by
then your ideas will change about how that ought. Just
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

(46:48):
those core deats, 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.

Speaker 1 (47:08):
Right. This kind of reminds me of the talk. I'll
have to go find it, booz. 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 I think somebody else talked about
some of the similar ideas with like hexagonal architecture and
things like that.

Speaker 3 (47:26):
Yeah, it's all part of it. Yeah, all these architectures,
we all have the same general idea. Hexagonal architecture, clean architecture,
ports and adapters, all of them have the same basic idea. Right,
get the details out here because they're vulnerable, Get the
business rules in here because they're not vulnerable. And these
are the family jewels here, you want those, right, everything

(47:49):
else out here, well, you can fiddle it that.

Speaker 1 (47:52):
Yeah.

Speaker 5 (47:53):
So I want to quickly talk about framework speed, right,
Like one of the biggest points of using a framework
is just like speed of development, right, 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 their opinionated. Just go with the opinions

(48:14):
and you can skip a lot of steps.

Speaker 3 (48:16):
Yep.

Speaker 5 (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

(48:37):
to that, like, once you have those like isolated and resolved, Like,
at what points do you make those trade offs to
slow down?

Speaker 3 (48:45):
Well, okay, 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 let's say that you've got some business rules and
you think they're pretty good, and you want to get

(49:05):
those up on a screen, and you don't want to
invest in writing your own screen stuff. So you think, okay,
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 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. Now,

(49:29):
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 probably going to 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

(49:52):
the commitment to the framework and live with that commitment.

Speaker 5 (49:56):
Let me let me sure you're 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 want to use active record,
they didn't want to store in a database completely understandable,
and basically what they've built starts to evolve into a

(50:16):
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 multidimensions 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. So

(50:39):
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, how do

(51:01):
you like, how do you surface these things across your team?

Speaker 3 (51:04):
Right?

Speaker 5 (51:04):
Like, is it just like peer review is enough or
are there like planning steps that you take to prevent it?

Speaker 3 (51:15):
Well, peer review would be a good thing to do,
especially if you've got some experienced people on the team.
Better than peer review would be pair programming. Right, So
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

(51:36):
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. And now let me tell you
what bad thing is going to happen to you because
you're 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

(51:57):
can actually use a different structure. This is architect level stuff, right.
Somebody who is they've got ten years of experience, fifteen
years of experience, and they can look at what is
going on and say, hmm, yeah, we need to protect
ourselves and rearrange this a little bit. Most of the

(52:20):
questions you've fired at me are I could rephrase as
how do I deal with the fact that everybody here
is under twenty five? Okay? And you know there's just
no good way to do that. It's important to have
people on the team that are experienced enough to prevent

(52:42):
the prevent the problems. Now. One of the problems with
making the commitment because at some point you may have
to decide I'm going to commit to this framework. I'm
going to live with that. But one of the things
you need to be able to foresee when you make
that commit is just what kind of an impediment the

(53:04):
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 that's a significant issue because as applications grow and
as they get more complicated, the initial help that the

(53:26):
framework gives you will often turn into a drag, something
that slows you down. Then now you've made the commitment,
you're going to be slow, 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,

(53:48):
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 five years. Uh, and we're
not going to run into any of these impediments. That's

(54:11):
a tough decision to make. Again, that takes somebody with
a few years experience.

Speaker 1 (54:17):
Yeah. One thing that's interesting because you're you're talking about
this and this kind of came to mind. I don't
know if it makes the point perfectly, but 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,

(54:40):
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 hedge fund. And at
a certain point they were using all the railisms in
the app and it was super slow. It took forever

(55:02):
to calculate all those calculations right to work through all
the transactions, and you know, because it had to tally
stuff at each transaction. 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

(55:24):
that I ran into was that rails it does give
you this nice interface to say, here's a sequel string,
do stuff, But then I was in this world of
I've got this really complicated sequel 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

(55:46):
lot of the stuff I wanted to do was with
just common table expressions, which is a feature in postgris cool,
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 to light for me, right,

(56:10):
And so there's all kinds of other stuff that I
am doing super fast because I'm so familiar with rails, right,
And I think, you know, 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 going to
use them. And so in this case, now, yeah, I'm
making another commitment to another version, and I have to

(56:31):
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.

Speaker 3 (56:37):
So you stated in an undeniable truth that does happen.
And I've seen that kind of thing happen more than
one time, where you get involved with the framework and
it's great for the first three months, and then the
next three months it's like and then the three months
after that is like help.

Speaker 1 (56:56):
Yeah, but in this case, it's not in my way.
It just doesn't offer what I need. And in order
to get what I think I need, I've got to
make another commitment.

Speaker 3 (57:06):
Yes, yeah, and rearrange a bunch of stuff. So then
you've got to solve.

Speaker 1 (57:12):
What I'm trying to get.

Speaker 5 (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

(57:35):
because you don't understand how it all works and it's
going to take too much time to tease that apart, right,
Like I don't build rockets. I'm not going to 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 yeh. So and sometimes using a dependency
gives it affords you that ability, right, and it's a great,

(57:57):
great tool to use.

Speaker 3 (57:58):
So I guess what I'm getting on is like how do.

Speaker 5 (58:01):
You weigh those things when you're trying to reason about
the framework? And 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

(58:25):
back to the framework, like you know, where's the cutoff.

Speaker 3 (58:31):
Where's the cutoff? Well, obviously this is a judgment call,
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 going
to be and it's not going to grow over the years,
it's just going to be a nice, simple little thing,
and there's a framework out there that just does that.
I'm going to use that framework. I'm going to make

(58:52):
a commitment to the framework. I'm gonna use it. And Okay,
I'm pretty sure that application is not going to grow.
I could get burned by that decision, but it's not
going to grow. It's fine, and you know, nine times
out of ten that'll be the right choice. Then then
you come up with another application. This application. The guys
asking for this are serious. They're they're looking ten years

(59:15):
down the line and they want they want some significant
stuff done. And so then you think, okay, I could
get the first year going and really easy with the framework,
and then after that they'd probably be hell to pay.
That might be the right decision, might be the right

(59:36):
decision because you've got time to market issues and startup
issues and stuff like that, but it might not be
the right decision. It's worth thinking about that one. It's
worth saying, Okay, you know, maybe there's a shorter path
to get to a high value, high value first release

(59:56):
without making a commitment to something that is going to
really hurt me a year or two down the line. Now, again,
all that's just all judgment call. But the first thing
you want to do is make that judgment call. Put
it in your head that you're going to make the

(01:00:17):
judgment call, and then you're gonna have to live with it.
The thing you don't want to do is just say, Yep,
we're going to the framework. No thought, just framework. That's
what you don't want.

Speaker 5 (01:00:30):
Yeah, make the decision to follow that up. Like, you know,
are there things in frameworks that lead you there?

Speaker 4 (01:00:39):
Right?

Speaker 5 (01:00:39):
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?

Speaker 3 (01:00:52):
Well sure, I mean the demo applications are often very evocative.
So you look at the demos and and you think, oh, yeah,
it's exactly what I want to do. And I don't
think I'm ever gonna want to do more than that.
You know, why wouldn't I use the framework? Of course,
I'm going to use the framework at that point, once
I've made you know, once I've been a little bit

(01:01:14):
careful about it. Exactly 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 app, just so that
you know, you know how how easier hard it is
for that first puncture, and then then you can help

(01:01:35):
that will help you make some decisions as well. You
guys are long past that. But some people who are
new and thinking, oh, let's just get you know, whipped
you do 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.

Speaker 1 (01:01:53):
Yeah, I was going to say, you know, essentially, the
point that I think both of you are making is
knowing that you're going to have to make this judgment
call at some point, right whether or not 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

(01:02:15):
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 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,

(01:02:36):
and the decision may be not yet.

Speaker 5 (01:02:40):
Yeah, so yeah, yeah, I was semi hopeful with all
these new AI generator things. As an example, Bolt dot
new right, like you just say, you give them all
your the requirements and then they're just like, you know,
it can help get your demo app ready. Obviously there

(01:03:01):
are some dangers there long term vision mind. Yeah, as
we've outlined here, you know, 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.

Speaker 3 (01:03:25):
So the application that I've been working on for the
last couple of years is a it's a a browser
for a social network. And I started on this and
I thought, okay, I really don't want to get a
gooe framework in here. So I found some dumb little

(01:03:47):
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 is really
bare bones. And I 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, we're not

(01:04:08):
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, it's really cool. You know,

(01:04:28):
I'm actually receiving messages and I can send messages and
now look at that. And then then I needed to
edit them, and you know, editing stuff on the screen.
That's a nightmare. I did not want to write, you know,
inside Macintosh again, I did not want to write the
whole gooey framework. And that's when I chose Swing. I

(01:04:50):
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. Okay, probably, okay,
I can commit to Swing. I already had the guts
of it, right, I had all the web socket stuff,
and I had all the fancy decryption and all that
stuff was going on. I just needed to bolt Swing

(01:05:12):
on and I had a nice isolation barrier and the Okay,
I can probably slip this in. No, there's just no way.
Swing is just so horribly opinionated, and I've fought through
that for a year. Just made the wrong choice, wrong
judgment call. I just can't go on with this application.
I'm going to have to rip Swing out and replace

(01:05:33):
it with something better. 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 realize, Okay, I'm going to make this

(01:05:55):
call and I hope it works out. It might not,
but don't make call frivolously, right, right, So just use
the amount of information you got solved. There's an old
saying it and it comes out of God, where was it?
I think it was the moon is a harsh mistress.

(01:06:16):
Do you ever read that book?

Speaker 5 (01:06:18):
That's a great book.

Speaker 3 (01:06:22):
Let me tell you a little story about that one before.
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, which is just the basic incrementalism.

(01:06:44):
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 out order a
little bit and it'll look different.

Speaker 1 (01:07:06):
Yeah.

Speaker 3 (01:07:06):
Great advice.

Speaker 1 (01:07:07):
Yep. All right, Well I'm gonna push us the pics. Okay,
this has been so good, Yeah, Valentino, do you want
to start us off?

Speaker 3 (01:07:23):
Sure?

Speaker 5 (01:07:24):
Yeah, all my pics 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 and actually
uses Rust to make a performance like schedules. So like

(01:07:51):
if you use a gem called ice Cube or something
like this, lets you like define ranges and and have
like a schedule object that can iterate over things really quickly.

Speaker 3 (01:08:01):
Uh.

Speaker 5 (01:08:01):
And he he built it uh using like a Rust
toolkit that snaps in to the Ruby subsystem called Magnets,
which is pretty sweet, uh to solve the specific problem.
Really cool jem. The other one is uh I co
worker David. He created this uh, this reapol a long

(01:08:24):
time ago called Octo.

Speaker 4 (01:08:26):
UH.

Speaker 5 (01:08:26):
That's like a knowledge management app that you run locally
on your system and it's just like really fully featured,
has and then encryption encryption support, and it's cross platform
and has all kinds of crazy support in there, and
you can think of it kind of like Obsidian or
something like that, but fully open source.

Speaker 3 (01:08:48):
Uh.

Speaker 5 (01:08:49):
And the last one is something I haven't gotten to
play with yet.

Speaker 3 (01:08:53):
Uh, but.

Speaker 5 (01:08:58):
My coworker Rob he created this thing called Cambian and
it's basically a way to configure come all and set
it up really easily on a Buntu and Debian systems,
So it's like a configuration tool for comal to just
make it easy. So that's that's really neat as well.

Speaker 1 (01:09:20):
Awesome, all right, I'm gonna jump into mine at some
of those. Am gonna go try out? By the way,
that'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

(01:09:43):
on the board is race car. The cargoes 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 two curve, and the way you move
is you you put down cards face down. Everybody does

(01:10:06):
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 there's 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 a mark on it, and then you
go that many. So if you go around the curve

(01:10:28):
too fast, then you take on that much heat. So
if it's a two curve and you go six, you
take on four 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 decent speed, and at that point you
can't go over because you're out of heat in your engine.

(01:10:50):
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 essential the the crux of the game, right,
and you can you can draft and then pass other cars.
You can. I mean, there there are other rules, and
there are like four or five racetracks. There are game

(01:11:13):
boards that come in the in the game. It's really
really fun. Board game Geek waits it at two point
one nine, 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

(01:11:35):
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 Satia Nadella. Satia is the CEO of Microsoft,

(01:11:56):
and he basically so the book is a little bit
I don't want to say it's like dated, but it
you know, it's not up to like twenty twenty four,
and so it ends, you know, in the late twenty teens,
you know, maybe around twenty twenty. And so he talks
about basically him taking over Microsoft and then kind of

(01:12:21):
leading it into this new age with cloud and stuff
like that, and talks about his background and stuff like that.
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

(01:12:44):
of Ford Motor Company and Bryce Hoffman. So Hit Refresh
is an autobiography. Ish Satia is the primary author American Icon.
He's an industry what journalist, I guess, and so he
got a lot of the inside track from a lot

(01:13:05):
of the people in forward and then wrote the book.
And anyway, it was it was really fascinating just to
listen through. Oh, this is how we solved this, This
is how we solved that. And you know, it goes
through the recession in two thousand and eight, and you
know some of the deals they were trying to work
out with the government, which I'll admit I don't love

(01:13:27):
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 going to
pick that. And then lastly, I think I might have
mentioned a few times that I am running on a
boon tou Now. I bought a desktop. The place I
got to from my laptop. When I'd run Docker and

(01:13:48):
run the stuff for any of my clients, my laptop
would just slow way down. And I was starting to
get into AI and that would slow way down too,
And so I decided I need a newer machine, and
so I started looking within the Mac ecosystem. Decided pretty
quickly that what I needed was not a laptop, and

(01:14:09):
so I looked at the MacPro and it was like
twelve grand for the one that I was thinking I wanted,
and I was like, that was a tough pill to swallow,
especially since my income's kind of been up and down
this year, but I was slow getting my client work
done because I'd have to wait for it to run

(01:14:30):
all the tests and stuff and 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 going to 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

(01:14:53):
a computer company called System seventy six, and so I
ordered from them. It did take a bit of time
because they custom build the desktop and then send it
to you, but this this one cost me like thirty
three hundred dollars instead of twelve thousand dollars. 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

(01:15:19):
instead of on Mac, but I've been pretty happy with it.
I know other people do work on Windows.

Speaker 3 (01:15:28):
I just.

Speaker 1 (01:15:30):
I don't know. I've kind of gotten 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.

(01:15:50):
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. It's into Windows, which works okay, right,
I don't hate it, but it was just like, oh,
I could just run everything on Linux, because That's how
I'm running my life anyway, right, I mean, all my

(01:16:11):
code deployees to Linux. And so yeah, I've been I've
been very very happy with it. It does essentially everything
that I want it to. The only things I've run
into that it can't do is you'll notice that I
have the green screen set up behind me. If I
want to run the green screen. I kind of have

(01:16:31):
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

(01:16:53):
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 have
the Adobe tools on my mac Book Pro and so
I'll run that there too, But I mean everything else,
it's just been and it's such a terrific dev environment.

(01:17:15):
I just I can't say enough good things. So System
seventy six is my last pick, Bob, do you have
some picks for us?

Speaker 3 (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 as 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

(01:17:44):
and it's written by Travis Corkran, 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

(01:18:04):
very modern meaning, current day political environment. So very funny
in a number of ways and very serious in another
a bunch of ways. So that's one book worth the read.
There's a there's actually two books in the serious plus
plus a bunch of short stories, all of them worth reading.

(01:18:27):
Travis is 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
programmers do that. Another book that's book series that I

(01:18:48):
found great, this goes back about five six years, is
the whole Bob of Verse series by Dennessee Taylor. I
think it is. And this is again it's the story
of a software developer, and I think I think that
Taylor is a software developer too, And it's the story
of a software developer named Bob who sells his company,

(01:19:09):
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

(01:19:30):
gets very interesting. 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 marginally plausible.
So that's a cool book, marginally plausible. Yeah, okay, And
then the last one is a new one and the

(01:19:55):
author's name is I can't remember the name of the book,
bok is Theft of Fire. Uh. And this this book
I have been Oh, Devin Ericson. Devin 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

(01:20:19):
sci fi because there's not a lot of good hard
sci fi. If you you know, you know, Mars was
a great story. Okay, yeah, we're yeah, the Martian that
Weir writes good stuff. But uh, 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,

(01:20:45):
great characters. So 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 Devin Ericson.
So my hope is that there's a rebirth in the
hard sci fi genre.

Speaker 1 (01:21:05):
Nice, all right, Well, I am also just gonna plug
your book, We Programmers. It's on Amazon. You go buy it.
Right now, and yeah, I'll look forward to Clean Coders
second Edition, all right, well, thanks Bob,

All Episodes

Evaluating Software Frameworks: Insights with Uncle Bob Martin - RUBY 666

Episode Transcript

Popular Podcasts

Stuff You Should Know

My Favorite Murder with Karen Kilgariff and Georgia Hardstark

The Joe Rogan Experience

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Evaluating Software Frameworks: Insights with Uncle Bob Martin - RUBY 666