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