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.
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.
Yeah, we're recording this.
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.
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.
Bag to maximize moisture, right yep.
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.
That's awesome.
It was good.
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.
In at least in North America and you're in Europe, like, yeah, well.
Not so much. No, Turkey's in North American phenomenon very much.
Yeah.
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.
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.
All right, let's get started with better know framework?
Hang on, you should we do the nineteen twenty seven Things Is episode ninety twenty seven.
Hey, you know that's a great idea. Yeah, I don't have anything prepared? What do you have?
Nineteen twenty seven was the year that Charles Limberg flew solo across the Atlantic. Oh yeah, yeah, New York to Paris.
Man, lucky, Lindy.
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.
Okay, all right, good, all right, so better no framework? Roll the music?
All right? All right, man? What do you got?
Well?
I don't know if you've seen this, but some guys to Avalonia, you know, which.
Is the UI framework.
UI framework that goes multiplatform and they recreated visual Basic six. What and you can even run it in your browser.
Oh my goodness, that's hilarious.
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.
I'm excited.
Yeah, right, it's really funny.
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.
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.
It's just funny, you know, fix it faster. You're not fixing it fast enough. Get fixing what's wrong with you?
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.
Maybe.
Yeah.
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.
Go on you know, the wayback Machine.
There was a website. What was it called? Was it Carl and Gary?
Yeah, that's right, Yeah, probably find some stuff there a.
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.
And you've got to measure for brain damage. Yeah, brain damage, brain damage, brain damage.
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.
And you could follow us on social media. Richard and I have been on x Twitter for many, many, many years.
Although it clearly seems to be collapsing now, like the followers are dropped by, people are deleting accounts.
Yeah, yep, so a lot of us are on blue Sky. I'm Carl Franklin b sky dot social.
And I'm rich Campbell dot b Sky dot social.
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.
Of a lot of the heck were you thinking?
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?
I did? I was actually a dungeon master for How did I know that?
Two years?
So somew.
Wow, okay, so the d's follow you wherever you go.
Yeah, actually I'm a bit said that. I'm not in tenacious D. But you know it's a two main group.
Right, Yeah, let's see those guys are squabbling too, aren't they If there's.
Yeah, yeah, but I don't I don't think they have a place for me. I cannot play guitar and I cannot sing.
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.
Yeah, that would be pretty obvious.
He is the Jack Black of dot I mean that's fair, all right. So what are we talking about today, Richard?
Well, I would say, let's talk about a bit about modernization and code Carter.
I would think, okay, so I called it code Charter, But what is code? That's what is code Carter?
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.
Lunking in the caves of code archaeology, you come up, yeah, virus where somebody has attempted to describe some code.
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.
Nice?
And that's where where the code carter comes in.
Well, and I guess the question is why do they think anything's wrong.
Usually someone is like, oh, hey, I wanted this feature like yesterday and I got it six months later.
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.
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.
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.
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.
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.
Mm hmm.
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.
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.
And you will give me, give me my compiler, nine thousand warnings.
Yeah, and go yeah, work in coffee.
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.
The size.
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.
And also I imagine which one is the most popular. How often does it get used versus these other ones on the periphery?
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.
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.
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.
Author, right, and then touch code.
Yeah, and that's a that's a knowledge silo, right, it's just one person who knows it.
I mean, you know, doesn't win anymore.
Given a vulnerability score.
Really yeah, precisely.
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.
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.
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.
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.
Problem for you for sure.
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.
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.
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.
No.
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.
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.
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.
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.
Yeah, and this this person is about to win the lottery.
Right, that's right. I like your positive version. I was supposed to being hit by a bus.
Yeah, I call it. I don't call it the bus factor. I call it a lot of factor.
A lot of factory.
Yeah I do, I do use the the inverse bus factor though.
Inverse bus do you know that one?
No?
No is the one where we where the bus missed you?
No.
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?
Right?
Hmm okay yeah. In other words, which people really need to take their hands off this code? Yeah we can. Yeah, yeah.
If these people weren't here, then things would be better.
Richard. That was your career, wasn't it.
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.
Feel like a bad reality show. I'm not here to make friends. Yes, inverse bus rule. I like that.
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.
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.
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.
Yeah.
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.
Right.
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.
Thing, and it doesn't really matter, right, It.
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.
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.
No.
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.
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.
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.
Yeah, lots of changes, lots of people.
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.
Okay, there's a yellow in there too, right.
You mean it say it's the same.
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.
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.
Yeah.
So again this one is again configurable. You can say, like, so you need to be careful what you want to visualize.
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.
Yeah. Yeah, so makes sense.
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.
Might Yeah that makes sense.
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.
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.
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.
Yeah, yeah, I mean even further, you have what's it called accidental and incidental complexity.
Exactly, and so the number ship could go down because you're limiting paths that should never have occurred in the first place.
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.
Yeah, you're going from two or more possible paths to one.
But you aren't you just sort of moving the if state into that implementation.
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?
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?
Now?
Yes? Right, which was to ask at the very beginning, can we get these features out faster?
Yeah?
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.
And fewer people but not but more than one.
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.
Ye I like that too.
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.
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.
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.
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.
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?
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.
So what do you what do you mean? Yeah?
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.
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.
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.
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?
How many.
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.
To the whole class.
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.
So what about the other question of how are buildings grouped together and separated in the map?
In the map they are just separated or grouped together based on package structure.
So how close together they are?
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.
So a belongs percentage.
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.
Interesting, So what's an architecture metric?
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.
Okay, yeah, and.
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.
Right, yeah, interesting, and I include the LinkedIn unit net.
Yeah.
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.
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.
Yeah, that's not quite the positive vibe.
Oh, come on, you're no fun man.
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?
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.
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.
You know, any it's one of those things where you know you should do it. Yeah, like that's going to.
And you should do it before another feature comes along where you have to continue along the same path.
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?
Yeah so Richard Gross, what's next for you? What's in your inbox?
In my inbox is Christmas? Yeah? Yeah?
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.
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.
Oh okay, where do the students come from?
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.
Sure. Yeah, it's a good resume piece because it doesn't have proprietary secrets and stuff in it.
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.
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.
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.
Oh yeah, you can actually three D print a model of your code?
Yeah, yeah, this is yeah, why not you can only visualize three D so much? Yeah on a two D space?
I I I like to say, code kata. Finally you can grasp your code.
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.
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.
It's really compelling. I like that a lot.
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.
Welcome. Hey, also thank you for having me on board.
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.
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.
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.
You got Jas middle Vans. Then I'm