Speaker 1: How'd you like to listen to dot net rocks with
no ads? Easy? Become a patron for just five dollars
a month. You get access to a private RSS feed
where all the shows have no ads. Twenty dollars a month,
we'll get you that and a special dot net Rocks
patron mug. Sign up now at Patreon dot dot NetRocks
dot com. Happy Thanksgiving all our US people. It's dot
net rocks. I'm Carl Franklin and.
Speaker 2: I'm Richard Campbell. And it's not Thanksgiving in Canada. That
was last month, right, yep, yep? So yeah, what can
we say, Richard? I mean I had a I did
my Thanksgiving last night. Oh nice.
Speaker 1: Yeah, we're recording this.
Speaker 2: Yeah, we're actually recording this on the Thursday, so on Thanksgiving.
Yeah in the US. But we did it yesterday. I
think that's clever. Smart.
Speaker 1: Yeah. I'm going to share my turkey recipe in the Lynx.
Basically what I did is I used a SOUVD preparation
for the turkey breast. Oh really on a turkey, Well,
just for the turkey breasts. Oh okay, so you dismantled
the turkey dismantled. It took out all the bones and
roasted those for gravy and took off the breast and
so those just get a little salt and pepper and
go in a in a you know, sealed.
Speaker 2: Bag to maximize moisture, right yep.
Speaker 1: And it was one hundred and forty five degrees for
two hours and it came out just perfect, that soft,
you know, tender. And then the legs I did. I
took out the bones. I can't believe we're talking about this,
but took out the femurs and then you know, salt
and pepper and little sage and those went in the oven.
So yeah, so those were my turkey parts.
Speaker 2: That's awesome.
Speaker 1: It was good.
Speaker 2: Hey, you know, turkey recipes are a thing this time
of year. What can I say the one time anybody
cares about turkey really well.
Speaker 1: In at least in North America and you're in Europe, like, yeah, well.
Speaker 2: Not so much. No, Turkey's in North American phenomenon very much.
Speaker 3: Yeah.
Speaker 1: I was listening to an interview with Eric Prepare from
La Bernadine, famous chef. He's like, the turkey is to
drive for me, I must have duck fat and you know,
goose liver. Pete.
Speaker 2: Yeah, listen, the right The only reason to cook a
cook duc is so that you have duck fat for potatoes. Exactly,
it's the only reason.
Speaker 1: All right, let's get started with better know framework?
Speaker 2: Hang on, you should we do the nineteen twenty seven
Things Is episode ninety twenty seven.
Speaker 1: Hey, you know that's a great idea. Yeah, I don't
have anything prepared? What do you have?
Speaker 2: Nineteen twenty seven was the year that Charles Limberg flew
solo across the Atlantic. Oh yeah, yeah, New York to Paris.
Speaker 1: Man, lucky, Lindy.
Speaker 2: He made it, and then he celebrated the snot out
of it. He didn't immediately on a tour won medals
like the whole nine yards, so he knew what he
was doing. Tried to run for president too, right, I think? Yeah, anyway,
there you go. That's what I happened to nine. That's
the best thing I have a nine twenty seven. There's
all kinds of crazy that I said.
Speaker 1: Okay, all right, good, all right, so better no framework?
Roll the music?
Speaker 2: All right? All right, man? What do you got?
Speaker 3: Well?
Speaker 1: I don't know if you've seen this, but some guys
to Avalonia, you know, which.
Speaker 2: Is the UI framework.
Speaker 1: UI framework that goes multiplatform and they recreated visual Basic six.
What and you can even run it in your browser.
Speaker 2: Oh my goodness, that's hilarious.
Speaker 1: Okay, so some caveats that the language support is limited,
but you get the visual Designer. You can save in
load projects in VB six format MDI interface.
Speaker 2: I'm excited.
Speaker 1: Yeah, right, it's really funny.
Speaker 2: I mean it is really awesome. I just couldn't remember
how to write VB six code, so, of course not.
It's been twenty years.
Speaker 1: And the compiler was ruthless, Like, you know, hey, if
you don't fix this problem, I'm gonna pop up a
dialogue like every five seconds and tell you to fix it,
tell you how wrong you yeah, and not give you
an opportunity to fix it.
Speaker 2: It's just funny, you know, fix it faster. You're not
fixing it fast enough. Get fixing what's wrong with you?
Speaker 1: Yeah? I guess if you know what code you're going
to put in there and copy and paste it, it's
probably gonna be a lot better your experience.
Speaker 2: Maybe.
Speaker 1: Yeah.
Speaker 2: I don't know if you have any old VB six
code around. I bet I do. I don't sit in
a volder somewhere. Goodness knows, maybe we'll have to.
Speaker 1: Go on you know, the wayback Machine.
Speaker 2: There was a website. What was it called? Was it
Carl and Gary?
Speaker 1: Yeah, that's right, Yeah, probably find some stuff there a.
Speaker 2: Few years ago. You know that would be a thing. Okay,
well that's what I got. Richard, who's talking to us today? Thanks,
grabbed a comment. I went to the Wayback Machine to
show nine to nine six one we did with old
Doc Norton. Remember Doc Norton in a while, Oh yeah,
we saw him on the twenty anniversary show talking about
agile metrics back then I was twenty fourteen. Lots of
comments on this show, and Mattias Carlo had this comment.
Admittedly it's from ten years ago. He says, I believe
there are a couple of flaws on some of the argumentation.
So that was the debate that Doc and you and
I were happy about this about setting goals on metrics.
While they can be good, the way they're described could
make it horrible. The reason why is that if you
take any measurement by itself, it has no meaning and
therefore can cause problems, like people gamify the metric. What
actually has to be done is to measure multiple points
and make sense of it all. So not one set goal,
but many, and so that would be goals for Velocity,
goals for bugs, goals for tech deck. Really the more
the merrier. Then you slowly start adjusting them all as
the team allows. So don't let any one goal be
the focus. But you left the tide of all these
different kinds of metricis. This idea has been proved many times. Example,
the whole IQ thing. There are people that have very
high IQ as we know, but not all of them
have other measures that are high like emotion que, social
que and so on, that are actually needed for things
to happen, and therefore lots of things never happen.
Speaker 1: And you've got to measure for brain damage. Yeah, brain damage,
brain damage, brain damage.
Speaker 2: So first you get to measure one measure with a
goal and see where's impacted. And you start measuring all
of them, and you try to get goals to all
of them like levers, and there's an optimal performance sitting
in there somewhere, just like an engine. Yeah, I can't
argue with that. I'm interested in getting more metrics, and
certainly the challenge is applying them well, not trying to
create problems, you're trying to solve them. So Mateias, thank
you so much for your comment and a copy of
music Coby. It's on its way to you. And if
you'd like a comic of music, codbe I write a
comment on the website at dot net Rock's com or
on the facebooks. We publish every show there, and if
you comment there and I read on the show, we'll
send you a copy of music go by.
Speaker 1: And you could follow us on social media. Richard and
I have been on x Twitter for many, many, many years.
Speaker 2: Although it clearly seems to be collapsing now, like the
followers are dropped by, people are deleting accounts.
Speaker 1: Yeah, yep, so a lot of us are on blue Sky.
I'm Carl Franklin b sky dot social.
Speaker 2: And I'm rich Campbell dot b Sky dot social.
Speaker 1: And we're also on mastadon I'm at Carl Franklin at
techhub dot social, and I'm rich Campbell at mass Social.
All right, now we got that out of the way. Yeah,
let's introduce Richard. The other Richard in the room, Richard Gross.
He's an it archaeologist at my Born Wolf. Did I
say that right? Richard you did all right, with more
than ten years of modernization experience. I love that an
it archaeologist, that's really cool, speaking.
Speaker 2: Of a lot of the heck were you thinking?
Speaker 1: Kind right, let's examine the ruins of this project. His
focus is on hexagonal architectures, hypermedia APIs, test dsls, and
the expressive and unambiguous modeling of the domain as code.
He enjoys mastering TDD bdd d Ddungeons and Dragons D
coupled design. I made that up that Dungeons and Dragons
part D and D. Yeah, decoupled design and even practices
that don't include two d's. He's also shaped the open
source project code Charta, which lets even non developers grasp
the quality of their software. Now I got to ask Richard,
do you play D and D?
Speaker 3: I did? I was actually a dungeon master for How
did I know that?
Speaker 1: Two years?
Speaker 2: So somew.
Speaker 1: Wow, okay, so the d's follow you wherever you go.
Speaker 3: Yeah, actually I'm a bit said that. I'm not in
tenacious D. But you know it's a two main group.
Speaker 2: Right, Yeah, let's see those guys are squabbling too, aren't
they If there's.
Speaker 3: Yeah, yeah, but I don't I don't think they have
a place for me. I cannot play guitar and I
cannot sing.
Speaker 1: Yeah, I think you know, if there was going to
be a Tenacious d dot Net Rocks guest band, and
it would probably be added up by Dylan Betty, don't
you think.
Speaker 2: Yeah, that would be pretty obvious.
Speaker 1: He is the Jack Black of dot I mean that's fair,
all right. So what are we talking about today, Richard?
Speaker 3: Well, I would say, let's talk about a bit about
modernization and code Carter.
Speaker 1: I would think, okay, so I called it code Charter,
But what is code? That's what is code Carter?
Speaker 3: Yeah, it's uh my when we named it, I asked today,
we just wanted to have two c's, so we just
picked a name which starts with a CNN. And then,
as it turns out, Carter apparently is Latin and it
means document or papyrus or something like this. Pyrus yea,
And yeah, it's just you know map, right, yeah, document
a code map. Yeah.
Speaker 1: Lunking in the caves of code archaeology, you come up, yeah,
virus where somebody has attempted to describe some code.
Speaker 3: Yeah, and I call myself that because I do a
thing called health check software health check. And you know
when you have an old code base and someone asks you, hey,
this is five million lines of code. Can you figure
out what's wrong? You immediately be like, okay, yeah, sure,
give me two years and they're like, how about three weeks.
Speaker 2: Nice?
Speaker 3: And that's where where the code carter comes in.
Speaker 2: Well, and I guess the question is why do they
think anything's wrong.
Speaker 3: Usually someone is like, oh, hey, I wanted this feature
like yesterday and I got it six months later.
Speaker 2: Why yeah, why is it taking a so long to
modify code? But boy, we've heard this theme over and
over again, right that applications build up craft and it
just gets harder and harder to make changes.
Speaker 1: And when you want to change something, well let's add this,
you get packaged oh that requires this, which requires this.
It's kind of like tugging on a thread in your sweater, right,
I mean, pretty soon the whole thing unravels and you're like, ah,
screw it, We're just going to rewrite it.
Speaker 3: Yeah. I think in science they call this the ripple effect. Yeah,
so you kind of throw a stone into the water
and then ripples and it creates other ripples, and you know,
it's not like one stone and then it's over, immediately
spawns new stones and they just ripple all across the
code base.
Speaker 1: So I know that you're a fan of ports and
adapters and hexagonal architecture and when you do health checks
and stuff like this. It just kind of brought to
mind that whole diagram. Do you try to when you're
trying to modernize something, do you immediately go for that
tool this is how we're going to redo things, or
for that pattern, I should say.
Speaker 3: I usually go for for mapping the code base first. Sure,
But yeah, when I when I have so see parts
and adapters, I love. I love the pattern, and yes,
I use it, and I use it in legacy code.
The problem I have is I don't know where to
start and where to apply it because the customer wants,
you know, new features, and he doesn't want me to
fix all the code. He wants me to fix a
specific part because that's where the feature comes in. And
when I know that part, yes, I usually do put
in ports, not like in a nice way, just put
in the ports. So I don't so when I write
a test, it doesn't touch the outside world. And because
that's sometimes way deep in the application, I don't like
inject it in there. I just put in some form
of configuration there so I can change it for my tests.
And yeah, definitely all ports of and adapters amazing, amazing
architecture style.
Speaker 2: Mm hmm.
Speaker 1: So the first step is to figure out what the
heck is this new relic we've discovered, and how does it?
You know, what are the component parts and how do
they interact with each other? And you know, maybe we
could avoid pulling out the entire sweater with one thread
to kill this metaphor to death.
Speaker 3: Yeah, And I mean that's not easy obviously, because like
you said, you know, it's it's it's tangled, so you
want to have it decaped. You want to be like, okay,
I just need to change this one. But the whole
point of why it takes so long is because, yeah,
this one thing is tangled to that other thing over there,
and it you know, it becomes like a like a
wacka mole game. And I think that the first step
is always to to have some form of observable observables
is wrong him because it's tied to operations, some overview.
And this is where we where we put in code cutter,
because it's a very very simple idea. When you when
you have something like like sonar or or I don't know,
independent going on or something like this that analyzes your
code base, it will it will give you metrics like
cyclomatic complexity or or code smells per file and everything,
and it will be kind of like like your email inbox.
It will say nine thousand issues or something.
Speaker 2: And you will give me, give me my compiler, nine
thousand warnings.
Speaker 1: Yeah, and go yeah, work in coffee.
Speaker 3: First, The interesting part is now, how can I how
can I like make this viewable in some form that
that I can digest it and I can say, okay,
this is the most important part. And we we we
stumbled more or less stumbled across a science tool that
mapped files to buildings. And these buildings have properties three.
One is the area, meaning how big is the building,
the height, and the color, and they just map the
whole code base one. One file is one building, and
then you can put different metrics on these buildings. And
when you when you view it from the top, you
can see something like lines of code. That's a very
typical lines of code. Well it could be, but right
now I'm just talking about the area.
Speaker 1: The size.
Speaker 3: Okay, that would be lines of code because then you see, okay,
it's a very large building when you when you view
it from the birdeye view. And then you can put
psychlomatic complexity on the height. And then the more business
logic is in the file, the higher the psychlematic complexity becomes,
the higher is actually the building. And then you have
large and tall buildings. And now you can can tweak
it a bit. Now it can be like okay, where
you can you can look at GET for example, you
can look at which file receives the most changes, and
then you can color this building for that file. You
can color it red and say like, okay, the thing
that has the most changes, make it red.
Speaker 1: And also I imagine which one is the most popular.
How often does it get used versus these other ones
on the periphery?
Speaker 3: Right yeah, yeah, right now we're we are a bit
in in the in the static territory where it can
just extract stuff from from from the code and extract
stuff from the from the GET history. It's a it's
a big focus in in Adam Thornhill's book, Your code
is a crime scene? How can you how can you
extract all this information it's a it's a great book.
He builds he builds his own tool called code scene,
which is based on the the work he did in
his book. Your Conde is a crime scene. Nice anyway,
So code cut now maps all of these files to buildings,
and then you can see like, Okay, this file is
very large, meaning lots of lines of code, it's very
high meaning lots of psychnomatic complexity, and it's very red
meaning it's changed all the time. And now you can
start doing a dialogue because people don't realize that they're
changing this file all the time, and they don't realize
how complex it is. And now you can have this
dialogue also not only with the developers, but also with
the stakeholders. It can be like, oh, look, we should
tackle this one. Because you change it every week or
you change.
Speaker 2: It to day. So by looking back through the GitHub history,
you're seeing where the resonance is in this code, where
everybody's working on it, where it's getting the most change.
Speaker 3: Yeah, but that's only only part of what I mean
when I say map map your code. That's that's one
one you just can You can go further. You can
be like, okay, so let's look at the code and
let's see which file only has one.
Speaker 2: Author, right, and then touch code.
Speaker 3: Yeah, and that's a that's a knowledge silo, right, it's
just one person who knows it.
Speaker 2: I mean, you know, doesn't win anymore.
Speaker 1: Given a vulnerability score.
Speaker 2: Really yeah, precisely.
Speaker 3: And then you can then you can also be like, okay,
who's still here or who's about to leave? Yeah, And
you can be like, okay, well, okay, two people are
about to leave, and they know the most complex part
of my code base.
Speaker 2: And they're the only ones you've ever touched it. Yes, right,
because you have all that information now, so you know
this is what you need to focus on.
Speaker 1: Yeah, you know, it's pretty powerful. Is they say where
I come from? That's wicked smat. It's very new England
wicked smat.
Speaker 3: The The fun part is you can also do the inverse.
You can be like, okay, so which buildings have like
the most authors? Yeah, and which is kind of the
inverse smell because now it's no longer knowledge silo. Now
it's probably a coordination bottleneck, right, yeah, because if you
have like eighteen people working on the same file, yeah,
that might also be a.
Speaker 2: Problem for you for sure.
Speaker 3: Yeah, in the end, I should probably put a disclaimer here,
you you know, a good Heart's law probably which says like,
when a metric becomes a target, it ceases to be
a good metric.
Speaker 2: Right, yeah, And I thought that was the comment I
had at the beginning of the show. Right, It's like
if you created a standalone metric and then every game
now it's you make it into a target. Now it's useless,
it becomes weaponized. Yeah yeah.
Speaker 3: Yeah. So so when we do the health check, we're
very clear as we want we want to help the people.
We don't want to be like, okay, you need to
I don't know, destroy this metric, drive it to zero.
Speaker 4: No.
Speaker 3: The the way we use code kata is just as
the start of a conversation. We don't want to end
the conversation. We don't to be like finger pointing everything.
We will to know where to start and then we
can have the dialogue right, and then we can figure
out I mean, there could be a billion reasons why
it's not bad. You know, it looks it looks bad,
it looks red and everything. Then you get to start.
Then you start talking to them and they're like, oh yeah,
well this one we don't really use that often. Or
you know, it's very complex, but we don't have to
change it at all, or something like this.
Speaker 2: I saw this with psychomatic complexity too, Like being complex
isn't automatically a sin. Being unnecessarily complex is kind is
a waste, But sometimes that complexity is essential. It's just
a place to look. It doesn't mean it's a place
to change.
Speaker 1: Right, Yeah, but it could certainly be a target. Makes
something an obvious target for refactoring. Yeah, you know, which
is one of the things, one of the tools that
you can make complex things easier to understand precisely.
Speaker 2: Yeah, it's just a question of do you need to
like if this doesn't go under a lot of change,
and it hasn't got a lot of problems, and it
happens to be complex. It's like, although you're talking about
the classic, right, it's complicated and only one person's ever
touched it.
Speaker 3: Yeah, and this this person is about to win the lottery.
Speaker 2: Right, that's right. I like your positive version. I was
supposed to being hit by a bus.
Speaker 3: Yeah, I call it. I don't call it the bus factor.
I call it a lot of factor.
Speaker 2: A lot of factory.
Speaker 3: Yeah I do, I do use the the inverse bus
factor though.
Speaker 2: Inverse bus do you know that one?
Speaker 1: No?
Speaker 2: No is the one where we where the bus missed you?
Speaker 1: No.
Speaker 3: No. The bus factor is you know how many people
or how many people can get hit by a bus
before the project stops? Right? Or how many people oh right,
I don't know, get married, win the lottery, whatever. You know,
there are billion possible things that very positively can tell
them they would leave. Inverse bus factor is how many
people need to get hit by the bus before the
project can start?
Speaker 2: Right?
Speaker 1: Hmm okay yeah. In other words, which people really need
to take their hands off this code? Yeah we can. Yeah, yeah.
Speaker 2: If these people weren't here, then things would be better.
Speaker 1: Richard. That was your career, wasn't it.
Speaker 2: Yeah, the old bulldog line. But well, the line I
use is like sitting around a table on the Monday
morning as the consultant thinking who do I have to kill?
Just trying to figure it out, Like nobody calls me
for good news, then call me because they need some
bad news to.
Speaker 1: Feel like a bad reality show. I'm not here to
make friends. Yes, inverse bus rule. I like that.
Speaker 2: That is interesting. How many people have to be removed
before progress can be made. Yeah, but I do like
this core idea of before I go messing with your code,
can we get a good look at it? And it's
not reading lines of code, it's these visualizations that show
you low ki of change, you know, low ki of inertia.
Like there's a lot of interesting parts there that you
can you can look at. I presume code Karta has
like a standard set of profiles that it can run
for you.
Speaker 3: Ah, that's a tricky one. So we we built cold
Kata in twenty seventeen, and we made its open source
from the beginning. Why because while we're not the product house,
we wanted to give back to the community. The tool
is not the thing we sell. We simply work in
health checks. And you know everyone is free to use
the tool.
Speaker 2: Yeah, because in the end, the tool is not is
not the skill set doing something about what the tool
tells you is the skill set.
Speaker 1: Yeah.
Speaker 3: And we split the tool into two parts. There's a
there's a shell or analysis part. And this analysis part
creates from different sources a file which we call the
c C Jason, the Code Karta Jason, and it has
a very specific file. It's it's it's a it's just
file name and then these are the metrics. And we
we have multiple importers for for different sources. So we
have sonar in there, we just have CSV in there,
we just have GET in there, we have SVN in there,
and you know, we can extract metrics from different sources.
Speaker 1: Right.
Speaker 3: And the idea was everyone can create their own parser
for anything they want, and if they don't want to
directly pipe it into the c C Jason, they can
just create a CSV and we have a CCV importer
for that. Now that is awesome from a flexibility standpoint
because you can visualize much more than CO. You can
be like, how let's visualize the population of America mm hmm,
every every file in quotations as a person, and this
person has different metrics, and you can visualize the whole
of us A with code kater and you know it
says code kanter, but you can't just you know, it's
just metrics in the end. So that's super that's flexible.
It's awesome, and you can also use it for for
for example, performance testing, you can you can map your
performance test. You can be like each test becomes a
file and the execution time is this long and so on,
and then you can even maybe compare different execution execution
times between the same tests and everything, because we have
a delta mode in there. And this is the amazing part.
The problem is that means it's generic, and that means
when you say execution profiles and everything, theoretically anything could
be in there. It doesn't have to be code metrics.
So we do have some profiles for the metrics that
we create. Because we know we don't call it lines
of code. We call it real lines of code because
we don't count the comments and we don't count the
empty lines. We just count well the code the compiler understands,
and that one part of the default profile. Our tool
just calls it cyclomatic complexity. You might decide to call
it something else, right, and then you know the tool
wouldn't be able to know that's the same.
Speaker 2: Thing, and it doesn't really matter, right, It.
Speaker 3: Doesn't really matter. It just matters for things like default profiles.
Because in the cord cutter you have each each property
of the building, you can just select whatever metric you
want for that. If you want, you can on size,
you can put the code coverage, the line coverage. If
you want to you can on the height, you can
put something completely different, you can put I don't know comments, right, sure,
and that's the power of the tools, but that's also
the dropping. Yeah, yeah, I'm explaining how generics make it
trouble some I'm sorry.
Speaker 1: Right, because if everybody can assign different properties to different
aspects and you don't have any kind of standards, then
you really don't know what you're looking at.
Speaker 3: No.
Speaker 2: I mean, a given team needs to agree on a
set of configurations and then stick to them, but at
least have some flexibility from team team. I'm thinking about
a show we did about a month or so ago
with lad Kunenoff where we're talking about balance coupling, and
he really got to the point where it's like, there's
a point where you can recognize there's enough coupling here
that maybe we should actually split this team up like
that they pull their files part so forth, and this
looks like a visualization where you could actually so, hey,
there's too many people working on on this, and they're
not necessarily working on the same area. So if we
split this class and then you know, have an interface
between them that's a fairly narrow one. Now, the complexity
goes down and the resonance goes down. So you know,
you made more files, but you may have made your
life better. And this actually might be able way to
visualize the difference. It's like, now we do a sprint
where we pull it apart and work through these things
and so forth. Now what does the visualization look like?
Like have we improved this is the tension down there
and then over time actually gets better. Like that's one
of the ways you would have unstuck the inertia. Going
back to you know, the original question here, which is
why can't I get a new feature out? It's like, hey,
if we build this other thing to pull this apart,
that frees us to move faster on this feature. In
some ways, it's like you've kicked some people off the
boat here, but you didn't really kick them out of
the company. They just took their piece of code and
isolated it so they can they can resonate separately from
the rest of the group.
Speaker 1: And that, guys, I'm going to ask you to hold
it right there while we pause for these very important messages.
We'll be right back. Did you know you can run
dot net nine on aws take advantage of dot net
nine's performance enhancements, dot net Aspire for Cloud native development,
and improvements to ASP, dot net and Blazer. Visit the
dot net nine on AWS support guide at aws dot
Amazon dot com, slash dot net. And we're back. It's
dot NetRocks. I'm Carl Franklin. That's my friend Richard Campbell. Hey,
and this is our friend Richard Gross. We're talking about
metrics and software getting better metrics. I wanted to give you,
Richard Gross, a chance to respond to Richard Campbell his
comment that he just made. If any I believe he'd
you agreed with, Yeah, all right, yeah, let me let
me elaborate bit on this.
Speaker 3: So the whole thing is exactly like you said, Richard.
It's you know, creating some disparency. Code is as immaterial.
You cannot touch it, you cannot see it, you cannot
feel it. We need tools to really understand it because
no one can keep that much complexity in their own head.
And one way it helps is definitely you can you
can see, Okay, this file has too many authors or
two little authors or whatever. We should split it apart
for you know, you have the metrics to prove Okay,
we should definitely split it apart it's a hot spot
and the next it's a hot spot.
Speaker 2: Yeah, lots of changes, lots of people.
Speaker 3: Yeah. And the cool part now is you can create
these before and after maps, so you can be like, Okay,
we're going to do a snapshot now, and we're going
to a snapshot in I don't know, two months or something,
and then you have a delta mode in there. You
just load two files and you say, okay, correct me.
The delta between that and that will show you the
change in either green or red meaning and then that
one is also configurable, so it can be like.
Speaker 2: Okay, there's a yellow in there too, right.
Speaker 3: You mean it say it's the same.
Speaker 2: Well, I would also think, like, you know, this was
this hotspot was red. Now we've done this pull apart,
like I'm hoping for two yellows at that point. Be nice.
It was like a yellow and a green like that.
I know, I've like at least turned the heat down
in that location.
Speaker 3: Ah, that's not what it does. It does. It looks
at the metric. So if youremetric before was cyclomatic complexity
and it says something like one hundred the yeah, one
hundred cyclomatic complexity. I don't think it has a unit.
I think it's just one hundred. If it has one
hundred before and now in the second file it has fifty,
it means you have a delta fifty, right, and it's
going to color the delta fifteen in whatever color you want,
usually red or green. For cyclomatic complexity, it makes sense
to color it green because it's usually a positive thing
if you reduce complexity. However, if on the height you
put code coverage, you want to color it. You want
to color it red if the coverage decreases, right, Yeah,
well no, it decreases specifically in the in the delta.
Speaker 2: Yeah.
Speaker 3: So again this one is again configurable. You can say, like,
so you need to be careful what you want to visualize.
Speaker 2: Yeah. I think the unit for cyclomatic complexity is paths, right,
because it's the number of it's it's an expression of
the number of unique executing paths through the code, and
the higher number, the more complex in it.
Speaker 1: Yeah. Yeah, so makes sense.
Speaker 2: Yeah. Now, of course, what I was describing is this
is probably a class that's been built that has different
areas of function, but they're colliding with each other and
they should probably be cut apart. But it is interesting
to think with their cycloamatic comy decrease when we pull that. Yes,
because you're taking a certain number of the paths and
putting them in a different class, so that the numbers down,
But the total number of paths probably isn't going to
go down between the two classes. The original class will
be a high number. Now we have two classes that
actually have a total number that's larger, but not much larger,
but overall lower per class.
Speaker 3: Might Yeah that makes sense.
Speaker 2: I mean, so you know, the original class had a
psychomatic complexity path of like two hundred. I pull it apart.
Now one of them is one hundred and twenty five
and one of them is eighty. So the total number
is slightly larger, but because each of the numbers are lower,
it's easier to work on that code.
Speaker 3: Now. Yeah, I mean, in theory, you're completely right, it
shouldn't change. Then amount of paths shouldn't change. No, the
in some cases it.
Speaker 2: Does, however, Well, because there's a concept here of intended
path an unintended path. This is why we create air
messages like you should never get here.
Speaker 3: Yeah, yeah, I mean even further, you have what's it
called accidental and incidental complexity.
Speaker 2: Exactly, and so the number ship could go down because
you're limiting paths that should never have occurred in the
first place.
Speaker 3: And even for incidental complexity, you can decrease the path
by using by by replacing an if statement with the
polymorphic dispatch. Right, So instead of instead of on having
if to if, that that you just call the method
on whatever class implements the interface. And honestly, I haven't
I should probably look this up, but in my head,
that would decrease the path.
Speaker 2: Yeah, you're going from two or more possible paths to one.
Speaker 1: But you aren't you just sort of moving the if
state into that implementation.
Speaker 3: Yes, and no, you're you're moving the if if statements
to the initialization of the class that implements the interface.
So let's say you have two if statements and different
points and they all both your place, both with the
same interface. Then you would decrease your complexity by one
because before your two if statements and afterwards you have
just the if statements in the place where you create
the class. And you know, one place has to decide
do I go left or do I go right?
Speaker 2: Right? Okay, all right, now I'm having way too much
fun with this because and it's all abstract conversation, like
you'd want to look at some code on this yes, right,
because the and the answer is it depends. But I
do like the you know, I come from performance testing background,
where it's like you test, you make changes, you test again,
is it improved? If not, you reverse ur right, like
you back that code out, So it's like you've now
used code card as to say, here's this point of friction.
I hypothesize that if we pull this apart like this
is one possible solution to this problem is that we
split this class. We argue about ways to do it,
we take a spike to do it, and then we
run the We run the code, we we do evaluate,
make sure it's still functional, then run the run the
tests again. Is it less complicated? And then the longer
term thing, given it is less complicated, are we able
to move faster?
Speaker 3: Now?
Speaker 2: Yes? Right, which was to ask at the very beginning,
can we get these features out faster?
Speaker 1: Yeah?
Speaker 3: And I can. I can promise you if you do this,
if you if you reduce the complexity, if you make
smaller fis I make smaller functions, you would get tested.
Speaker 2: And fewer people but not but more than one.
Speaker 3: I don't know. They are develops that are very very fast,
and some of them are a bit of a team hazard.
They are called they are more of a technical tornado.
Speaker 2: Ye I like that too.
Speaker 3: Yeah, you deploy them and like a tornado, they run
through it and after what it's finished, just don't go
back there again.
Speaker 2: Well, because there's a whole separate subtext here that I
would use code Cardiphora as a PM, which is what
are my risky code here, which is only one person
knows about it. So it's like where I want to
do code reviews and where I want is to get
coverage on some of this code so that other people
are aware of it. But that is not the problem
that was presented as at the beginning, right of the
presenters at the beginning is I can't get new features out.
Speaker 3: Yeah, yeah, I mean the reason you might not get
many features out is because it's all tied to one person.
So it could be related, but it could be a
completely different and separate business risk.
Speaker 2: You're right, And again the code now manifestation of the
organized that this person touches so many things. They are
a gatekeeper to all change Yeah.
Speaker 1: I've been sitting here thinking of ways in which, you know,
problems can arise when when you use this tool, and
what you can do to minimize them. And one of
the things that hits me is, all right, let's say
run code Karta on your your solutions and your projects
and all that stuff, and you come up with what
looks like a city map. Now, have you ever seen
a situation where the aerial view looks like all of
Los Angeles versus a little rural you know, intersection and
a country pub and a couple other buildings, Right, I mean,
what do you do when it's just so big that
the visualization becomes meaningless? Can you like zoom in on
a particular part of it or group them group the
buildings together in some way so that you I mean,
where do you start when it's Los Angeles?
Speaker 3: So I would say it doesn't look like like Los
angel It looks more like the city from Judge Dread. Yeah,
I sorry, I haven't read the comics, but I I've
seen the movie with the color urban.
Speaker 1: So what do you what do you mean? Yeah?
Speaker 3: For those two so in Judge Drat they have this
the city are just called mega city one two three okay,
and they have these huge skyscrapers, but they are not
like a skyscrapers like the complete city block. Yeah, and
what do you mean by that is, yes, you will
find large buildings that but they will usually also have
lots of lines of code and like these huge blocks
in there and not small skyscrapers, but blocks tall as hell,
but blocks.
Speaker 2: Right, But in between there are the smaller ones, right,
Like it's it's a handful of mega structures and then
lots of littler structures. Yeah.
Speaker 1: So is there some city planning that needs to happen
where we put all the big ones together and at
the core of the city and then sort of spiral
out to the smaller and smaller and smaller ones or
is it strictly there next to each other because of
how they're inter how they interact with each other.
Speaker 3: Oh, that's a different topic. Let me just go through
my process because you said, okay, what do you do
when you have all these big buildings? Yeah, yeah, yeah,
I I do a deep dive. I always start with
the map and the high level view and it scales
great to about four or five million lines of code.
That's it's good for that. I haven't tried ten million,
but it should also be able to scale to that now. Anyway,
when I see something large and red, and I usually
look at it from different perspectives, I'm like, okay, this
is large and red. Is it large and red here?
Meaning it's changed all the time, it has high complexity.
I'm looking at it from different view how many code
smells are in there? How many authors? And then I
sort of collect all the buildings that are interesting, and
then I deep dive, meaning I opened the file and
I try to understand, Okay, is it just a false
positive or is it really a true positive? True positive
meaning this case I found something I should be changed.
And at that point I yeah. In the end, experience
takes over things like how many code smells do I
find there?
Speaker 1: How many.
Speaker 3: IOSP violations do I find? And so on and so on?
Sorry iosph got integration operation separation principle. There we go.
The idea of this principle is you have a function
and this function is either integrating functions other functions, or
you have a function that is actually doing an option.
You cannot have both in the same or you cannot
have integration operation in the same place. The benefit is
Usually it leads to much more readable code and much
smaller code because if you cannot in an operation, you
cannot call another function. You always have to return to
the integrating function. And there's even architecture based on this,
but I forgot the name of that where you don't
only apply to functions in a class, you apply.
Speaker 2: To the whole class.
Speaker 3: And from there I usually start the conversation with existing developers.
If they are still there, doesn't have to be the case,
and if not, I first or I found targets that
I should look at, maybe maybe change. But from there
I also need to find out what do you want
to do in the future, you know, what are the
next targets? And maybe that leads to this large red
building that which I did a deep dive into, being like, okay, well,
I don't have to change this now. I have to
change this in six months or so, right, and yeah,
now now it's all NITTI pretty details. Now it becomes
can I do an early return or a guard statement
instead of having deeply nested IF statements. Can I abstract
away some domain model in there? Can I extract some
form of units, some form of ID and make it
a domain model, and that yeah, also hard to talk
about when you don't have code in front of you.
Actually talked a bit about this whole process in my
in my target at build stuff, domain rediscovery patterns or
legacy code.
Speaker 1: So what about the other question of how are buildings
grouped together and separated in the map?
Speaker 3: In the map they are just separated or grouped together
based on package structure.
Speaker 1: So how close together they are?
Speaker 3: Essentially where where developers thought they should fit. And if
you in the name space, you know where if someone
put in the same name space, it's going to be
right next to the other thing. But we always had
this idea of putting sort of this belongness indicator in there,
give it, give it a color on we We didn't
implement this, but the the idea has to was you
go either based on temporal coupling or change coupling, or
which is easier to comprehent you go based on import
statements and and just general dependencies. And then you say, okay,
this file doesn't depend on any of the other files
around it, but it depends on files in a completely
different package. And then you mark that as read.
Speaker 1: So a belongs percentage.
Speaker 3: Yeah, how many classes does it interact with that are
next to each other or one level below or versus?
How many things does it depend on that are outside
of its scope? And we we recently experimented a bit
with this by putting architecture metrics into the map as well.
Speaker 2: Interesting, So what's an architecture metric?
Speaker 3: Have you heard of arc unit dot net? It's a
I think it's not originally as a Java program or
a Java tool. It got ported to dot net. The
idea is just to write your architecture rules as code
and then validate them with unit tests. So what do
you mean by architecture. It provides a fluent DSL. It
can be like anything with the ending service is only
allowed to talk to something ending in repository or anything
in this package, or anything in the domain logic package
is only allowed to talk to other domain logic packages,
but not on infrastructure packages.
Speaker 2: Okay, yeah, and.
Speaker 3: Then you can write rules and problems and lexi code.
You well, you will have lots of violations. So that's
when you go ahead and you freeze all those violations.
Say okay, I will accept those, right, but they don't
want any additional ones. And these frozen violations they usually
come from files, and then you can make the building
larger the more architecture violations it has, and you can
be like, oh, okay, this one has lots of architecture violations.
That is probably a good place to refector as well.
Speaker 2: Right, yeah, interesting, and I include the LinkedIn unit net.
Speaker 1: Yeah.
Speaker 2: So just this idea of thinking about how well have
I implument an architecture here and being able to test
it and again it'll give me eyes on problematic code.
Another way to find it.
Speaker 1: Yeah, it would be fun is if you handed out
violation tickets to those developers who have violations in architecture.
It's like, okay, we're finding you, you know, so many dollars.
Speaker 3: Yeah, that's not quite the positive vibe.
Speaker 1: Oh, come on, you're no fun man.
Speaker 3: I've been in this experience too many times myself. When
you yeah, when you have a code base and in
your head it just looks beautiful and everything and you're like, ah,
this only depends on that, and then for the first
time you put in arc unit right, wait, I'm not
allowed to do that and that and that and that
and ah what did I do?
Speaker 2: Yeah, it's like turn that off. I don't want to
look at that again, it makes me sad. I don't
have the time to comprehend this right now. But again,
it's like we should all be kind to each other.
There's always you know, of course, again, like any of
these tools, just because it puts a focal point on
that doesn't mean it's incorrect, just that it should be scrutinized. Yeah,
so it's like, yeah, we may have violated the principle there,
but we violated for a good reason. Yeah, what was
the line I used a while ago? You know, every
every application has ugliness. It's just a question of do
you know where yours is definitely, Yeah, it's largely unavoidable.
You will have some ugly It's okay.
Speaker 1: This conversation has made me go over in my mind
the architecture of an app that I'm developing for a
customer right now, and I've already figured out, you know,
has actually happened before we started this conversation. But you know,
a refactoring that's going to be painful, which is usually
involving the creation of several interfaces, just saying but.
Speaker 2: You know, any it's one of those things where you
know you should do it. Yeah, like that's going to.
Speaker 1: And you should do it before another feature comes along
where you have to continue along the same path.
Speaker 2: Keep doing now, keep putting duct tape and baling wire
on the thing. It's like I could fix this thing
or I could duct tape. It's some more right, Yeah,
been there? Sure?
Speaker 1: Yeah so Richard Gross, what's next for you? What's in
your inbox?
Speaker 3: In my inbox is Christmas? Yeah? Yeah?
Speaker 2: Yeah? Yeah? It is upon us, isn't it? Without a doubt?
I noticed. I just was looking at the contributor list, like,
lots of people have contributed to code Karda. I mean,
obviously there's a handful of key people, but you've got
a long list. So how do you have so many
people involved in the project.
Speaker 3: Yeah? We that's the interesting part. It's it's one it's
like our most crucial tool for health checks because five
million lines code without tool not at all, and it's
mostly done by working students.
Speaker 2: Oh okay, where do the students come from?
Speaker 3: Yeah? We we are very very fortunate to work together
with with local universities and they they journals and become
working students. And I was I was like, really like
giving their opportunity to work on this because it's it's
open source they can show to anyone else. There's no
NDAs or something in the way.
Speaker 2: Sure. Yeah, it's a good resume piece because it doesn't
have proprietary secrets and stuff in it.
Speaker 3: Yeah and I yeah, basically they can also play around
with it a bit because it's it's it's life, it's
in production. They they can learn a lot about about
what quality and about working on a on a true piece,
and they they mostly do it by themselves.
Speaker 2: Interesting, and you do you have a I mean, how
much supervision do you need to give them? Really? Just
get them sort of into a buildable state, take a
look at the issue list that's sitting there for the
project and take one on kind of thing.
Speaker 3: Well, it depends on the developer. Usually you have you know,
in the beginning, when your junior developer comes on on
your team, you you are more and more specific about
what you what you tell them, and later on you're like, yeah,
go to town with it. Actually, that's that's where our
three D printing feature came from.
Speaker 2: Oh yeah, you can actually three D print a model
of your code?
Speaker 1: Yeah, yeah, this is yeah, why not you can only
visualize three D so much? Yeah on a two D space?
Speaker 3: I I I like to say, code kata. Finally you
can grasp your code.
Speaker 2: Literally physically grab onto it. But I would also imagine
if we had a year long making the code better initiative. Yeah, yeah,
idea that you would print a model at the beginning
of that, a fortam model at the end of it. Yeah,
because every you know, the terrible thing about performance tuning
is when the code performs well, nobody notices. They only
notice when it doesn't, So the moment you fixed it,
they forget about it. At least, this would be tangible.
Remember that ugly red tower we used to have in
the middle of our code, It's not there anymore. Yeah,
very very true. Yeah, I really appreciate that. That's a
great idea.
Speaker 3: It's a it's a really interesting experience because when you
when you print the first model, you will have lots
of tall, large and fat buildings, and then two years
later or something they would be tiny building. I mean
some of them are still large, yeah, but you know
they're much tinier. They have much more, much less lines
of code, and you would really see how how the
same map now suddenly it's much more divided into into
smaller pieces.
Speaker 2: It's really compelling. I like that a lot.
Speaker 1: It's just great stuff. And you know, wow, I love
hearing about tools this and I'm sure our listeners did too.
So thank you very much, Richard Gross for telling us
about it.
Speaker 3: Welcome. Hey, also thank you for having me on board.
Speaker 1: Happy to have you, absolutely Yeah. All right, and we'll
talk to you, dear listener next time on dot net rocks.
Dot net Rocks is brought to you by Franklin's Net
and produced by Pop Studios, a full service audio, video
and post production facility located physically in New London, Connecticut,
and of course in the cloud online at pwop dot com.
Speaker 4: Visit our website at d O t N E t
R O c k S dot com for RSS feeds, downloads, apps, comments,
and access to the full archives going back to show
number one, recorded.
Speaker 1: In September two thousand and two. And make sure you
check out our sponsors. They keep us in business. Now,
go write some code. See you next time.
Speaker 3: You got Jas middle Vans. Then I'm