Episode 122 - Managing Dependencies with M. Scott Ford

Embedded Player

The .NET Core Podcast

Episode 122 - Managing Dependencies with M. Scott Ford

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

Legacy code is a term used to describe systems that are difficult to change due to a lack of understanding, tools, or knowledge. It could be a system that hasn’t been touched in years or a newer system that has become difficult to change due to choices made during development. However, it is imperative to change the negative attitude towards legacy code and make it something that people don’t view as a bad thing. There is value in older systems that are difficult to work with, and incremental improvements can be made without disrupting utility.

In this episode, we discuss the issue of legacy code, and our guest - M. Scott Ford - pointed out that replacing a legacy codebase with something new is not always the best approach. The assumption that starting from scratch will be better is often based on a narrow focus on one aspect of the system, rather than considering the value of other parts. “Certainly replace a kitchen, get a new kitchen, but you often don’t need to bulldoze the entire house to get a new kitchen,” said M. Scott Ford. Instead, he suggests an incremental approach to modernization, where improvements are made without disrupting utility – adding a new lane to a bridge rather than tearing down the old one and building a new one, for example.

It’s also important to understand the differences between technical debt and legacy code. Technical debt involves intentional or unintentional choices made during development that result in technical challenges, while legacy code can have personal or people issues that make it difficult to change, such as lost knowledge due to team members leaving. It is crucial to have metrics and logging in place to determine the value of features and code, and to surface this information in a way that makes sense to decision-makers. Business decisions should be informed by data on how much energy and engagement a feature or piece of code requires and whether it is worth keeping based on its impact on the budget and customer base.

Collecting data and analytics must be done with respect to customer privacy and in compliance with regulations such as GDPR. Logging and metrics are important for making informed decisions about which features to prioritize and improve. Writing tests is a personal accountability process to ensure that what is built is what was meant to be built and provides durable value for future maintenance.

Inheriting a legacy codebase requires understanding the code and its usage, implementing logging and metrics, and making informed decisions about prioritizing improvements. However, sometimes it’s essential to have someone with fresh eyes joining a team, as they might spot things that others have become blind to over time.

In conclusion, legacy code is not necessarily a bad thing, and it’s vital to change the negative attitude towards it. Incremental improvements can be made without disrupting utility, and it’s important to have metrics and logging in place to determine the value of features and code. Collecting data and analytics must be done with respect to customer privacy and in compliance with regulations such as GDPR. By understanding the code and its usage, implementing logging and metrics, and making informed decisions about prioritizing improvements, we can turn legacy code into an asset.

Episode Transcription

Hello everyone and welcome to THE .NET Core Podcast. An award-winning podcast where we reach into the core of the .NET technology stack and, with the help of the .NET community, present you with the information that you need in order to grok the many moving parts of one of the biggest cross-platform, multi-application frameworks on the planet.

I am your host, Jamie “GaProgMan” Taylor. In this episode, I talked with M. Scott Ford of the Legacy Code Rocks podcast about managing your applications and legacy code. We talked about why metric, analytics, and logging are so important; we talked about what legacy code is; and Scott also talked about why tests are so important to him.

Along the way, Scott shared some amazing tips for developers regardless of where they are in their journey, and regardless of the technology stack that they use - including how he uses pact.io to make integration testing a breeze.

He also shares some of the ways that he stays up to date with all of the libraries and packages that are out there - pro tip: it’s related to our chat about metrics, but I won’t spoil anything for you just yet - So make sure that you stick around to the end of the episode to find out about those.

So let’s sit back, open up a terminal, type in dotnet new podcast and let the show begin.

Jamie

So the first thing I’d like to say, Scott, is thank you ever so much for joining me on the show. I know you’re an incredibly busy person. We’re all really busy. Everybody’s busy.

Scott

Yeah, thanks for having me.

Jamie

Absolutely. Hey, you’re very welcome. You’re very welcome.

So I thought before we start talking about managing dependencies and legacy code and things like that, I thought maybe we could have a quick chat about you and the content that you put out there. That way, if there’s someone listening to this who hasn’t had a chance to check out your stuff, they can go, “oh, cool, I’ll click this thing, because Scott sounds awesome.”

Scott

Yeah. So I guess some of the ways to kind of catch up with me is to head over to Corgi Bytes. There you can find the company that I run with my business partner, and then there’s an online community that we started called Legacy Code Rocks. It’s at Legacy Code Rocks, we’ve got a podcast, a Slack community - a Slack based community - and a weekly virtual meetup that you can attend. There’s information for how to do that over in Slack. So those are things we’ve got going on for folks who are interested in all things legacy code or think they might be.

Jamie

Awesome. Well, yeah, definitely go check those out.

Before we even start with any of that. What is legacy code? Right? Because I have perhaps a different view to everybody else. Everybody’s got their own view, right? So what is Scott’s definition of legacy code?

Scott

I think of it as anything that’s hard to change, and the reason it could be hard could be that you can’t understand it, or it could be that you don’t have the tools, or you don’t have the knowledge yet. Right. But there’s some impediment to making a change. It’s not easy to change. To me, that’s what makes something kind of legacy. So there’s the more traditional things we think of the aging system in the corner that hasn’t been touched in years, that certainly fits that definition. Those things are hard to change; but it can also be something that’s only a year old and it could have gotten in a state where it’s difficult to change because of choices that were made, and could be perfectly reasonable choices that were made but the result of those choices has made it tough to make changes.

Jamie

Okay, so is that different to just straight up tech debt then, in your opinion?

Scott

I think it is because the reason it can be hard can be that there’s, like, no documentation or that the person who worked on it isn’t around anymore; or it could be… there’s lots of reason. For me, when I think of tech debt, it’s something that was taken on intentionally or perhaps not intentionally, but maybe accidentally through choices that were made. And it’s more of a technical challenge right? [it’s] in the name. But I think you can also have more kind of personal people issues that make it difficult. “The reason it’s hard to change now is because the knowledge is lost,” it will be a technical challenge to figure to kind of recreate or recover that knowledge in some form but that’s not really debt that the team took on. The team doesn’t really make a choice to have somebody decide that they’re going to quit. Right. I don’t think of that as a debt that the team has taken on.

Jamie

Okay, that makes sense. Yeah. Because sometimes there is a technical decision you have to say, “look, we’ll do it this way and we’ll just have to deal with it and we possibly can change it in the future. But to change it would be more difficult.”

Scott

Right, yeah. I think the technical debt involves choices about the solution and they can be choices we realize we’re making, which I think is the obvious technical debt but then there’s like the unobvious technical debt and those are the choices we don’t realize we’re making. But I think it all comes down to it. It’s the result of a choice that was made.

Jamie

Okay, well, let’s talk a little bit about then a little bit about the Legacy Code Rocks podcast.

Scott

Okay.

Jamie

Because I’m a big fan and I know that there are some people…

Scott

Thanks.

Jamie

You’re very welcome. I know there’s some people in the Tabs and Spaces community who are big fans too. Let’s talk about that for a moment. So is that just you and your co-hosts just sitting around going, “legacy code is the best; greenfield sucks!” is that what you doing?

Scott

No, our mission is more to try to change the attitude towards legacy code to make it not a pejorative. So to make it something that people don’t look at as a bad thing. Right. It can be something that brings you joy. So really trying to change the attitude that is given to a lot of projects that are in this state. And there’s tons of attitudes I’ve encountered over the years, but almost all of them negative before us really kind of taking on the journey of trying to counter that, but nobody wants to. I’ve heard things like, “nobody wants to work on a legacy code project,” or like, “oh, it’s just a legacy mess. It’s a nightmare,” or people not wanting to touch it because they’re afraid that they’ll ruin their resumes or things like that. There’s lots of negative reasons and negativity or, “the people who built it didn’t know what they were doing,” or “why would you even put up with that?” Instead kind of making it about what’s possible with these systems and really trying to counter the narrative that everything new is amazing. Right. Like, new equals amazing. New equals better. New equals best. That’s not always true.

I think there’s a lot you can learn from older systems. There’s a lot you can learn from systems that are difficult to work with. And I think just encountering one of those systems and then deciding, like, “oh, it’s a mess. Let’s start over,” that’s a waste. So I see that as a waste. I think my bias is almost always towards figuring out a way to harvest and resuscitate and restore a system that is in this state where it’s difficult to work with. And especially if it’s still providing value, it’s still valuable, it’s still doing something for somebody. So to think that it could be thrown away and built from scratch and done without error or done quickly or I feel like that’s almost always wrong. There’s almost always things that get missed.

Jamie

Sure. I can see that. And I think it’s something that I feel doesn’t happen so much in other engineering disciplines. I mean, I may be wrong. Right. My only experience of engineering is software engineering right, right. Like the metaphor I was going to use was, like, “there’s this bridge. It was built in the 50s. It works fine, but it’s legacy. Let’s tear it down and build a new one.” Like why? It works, don’t it?

Scott

Yeah. I think, again, I don’t have that background either. So I guess if there are civil engineers listening, maybe they can educate us. But I think I can imagine that with most engineering disciplines, there are ways to solve problems that come in and out of favour. There are ways to ways to use materials in different ways. There’s new knowledge about environments. There are changes in the way that structures get stressed. I can imagine that, I think, obviously a bridge that was built with horses in mind, might not stand up to automobiles. Right. That just seems reasonable to me. I think we see similar to challenges with the software systems that we work on, in that if it was originally created with one particular use in mind, then in its current form, it may no longer be of service.

But I think for me, when we think about bridges and kind of comparing up the software systems, the goal may be to have a new bridge. For me, what should never happen is a complete halt in traffic. So I think tearing down the old bridge and then building the new one, I think is something that should be avoided.

Instead, I think work on building another lane of the bridge that can accommodate the new use case that’s been discovered, or that can be built with a more updated approach or different materials. And then when you’ve got enough lanes to support all the traffic, then you can tear down what was essentially the old bridge. But you never had a disruption in traffic. People were able to use it. For me, that incremental approach to modernization is really key and really important and recognizing that we can make improvements where we end up with something that’s new. But we don’t have to destroy utility in order to achieve it. We don’t have to create a service disruption.

Jamie

Sure. I guess to bring it back to development. You can create something that extends rather than replaces, right. Like you say, by adding a new lane.

Scott

Or even with the bridge. I can imagine this might be possible. But you could build a shell around the bridge, around the existing structure, or replace the support structures one by one with different material. And so you’ve got modern support structures supporting older pieces, and then you can swap out the other, older pieces one at a time.

The Ship of Theseus is another metaphor that I think of a lot in these scenarios. And that’s, for people who might not be aware, is this idea that if Theseus and the folks on this boat, if they repaired the boat as they were on their journey, and they replaced every board as it as it aged out and at the end of their journey, if every single board had been replaced, was it the same boat? It was kind of the thought experiment, right. And to me, that’s what keeping something up to date looks like is replacing those bits and pieces at a time and instead not saying like, “oh, we’re going to put into this port and we’re going to build a completely new boat, and nobody can travel until the new boat is built.”

So to me, I like those more kind of incremental approaches to making things better. Anytime there’s a suggestion that where people say that you can’t make improvements and do other things at the same time, I kind of reject that. I’m like well, I really push on that and say, “well, why not? Like, is that a technical reason or is it just you think it’s going to be harder or you’re worried about how much it might cost? What is the motivation for saying that it can’t be done?”

Jamie

Yeah, exactly. I agree. It feels like it’s a conversation that sometimes those in charge, or maybe those who are in charge of the team of developers are like, “no, replace it. It’s getting too hard to deal with.” And maybe it’s not. Maybe it’s just their misunderstanding or maybe us as developers aren’t communicating it correctly. It’s a difficult one. Right.

Scott

My experience has been over the years, it’s the developers advocating that the tear down and start over happens. And it’s usually the people who have paid, it’s usually the people who are in charge of the budget who are pushing against that and saying, work with what you’ve got. This tension gets created because the developers get it in their head that all of their current challenges could be solved by starting over from scratch. And the people who are in charge of the budget are very resistant of going down that path. And so you have this animosity that broods, I guess - animosity that brews - where the folks who are in charge of the budget start to get really frustrated with the developers always complaining. And the developers feel like they’re not given the freedom to make the choices that they feel are best.

And so I think that’s where that can come in. And I think that’s where a lot of the negativity about older code bases can come from. There’s this assumption that it will be better if we could do it from scratch. Whatever dimension better is usually being imagined. In my experience. It’s usually only one or two dimensions, right? They’re imagining that an aspect of the system will be better, but they’re they’re overlooking lots of other parts. So I have like a slide and a conference talk that I’ve given in the past where I imagine somebody complaining about their kitchen and so they bulldoze their house and they’re like, “oh, but all those other rooms are actually okay, I was just upset about the kitchen, but now we’ve bulldozed the house.” I think there are times where we can get so focused on one aspect of the system that we’re frustrated with that we completely discount the value of the other parts.

Jamie

I love that analogy.

Scott

Certainly replace the kitchen, get a new kitchen, but you often don’t need to bulldoze the entire house to get a new kitchen.

Jamie

Yeah, I love that analogy. I’m all for a good metaphor, right? Yes, always. I love a good metaphor because it is truthy, right? It gets the point across. And I love that one because it is almost exactly what we’re doing when we’re advocating for starting again. And it’s like, especially if you inherit a code base from another team or another entity. Right. I often sit and think, well, “how big headed do you think you are? Or rather, how big headed are you that without even looking at the code or the requirements, you just know that it’ll be better if you do it?” Because that’s what it comes down to. Right?

Scott

Yeah. So there’s this poem by Richard Kipling. I probably just butchered their name called The Palace. And it it talks about this, you know, this King Mason who, you know, comes across this spot where they want a palace to exist. And because they are a King and a Mason, they both have the resources and the know how to build a palace. But when they get there, they discover all of these pieces of stone that have this warning scrawled on them. And the warning is, “after me cometh a builder. Tell him I, too, have known.” And the King Mason is convinced that this will be the perfect spot for a palace. And so he dives in and starts building a palace there and gets this point where realize it’s not going to be possible. And all those discarded bits of stone with the warning on it, maybe that person knew what they were talking about. And so the poem ends with that King Mason tearing down the attempt that’s in progress and then scrawling on each one of the stones the same warning, “after me come with a builder, tell him I, too have known.” And so I think it captures that refusal to acknowledge that the people who tried before me could have possibly known what they were talking about in that moment when you have to kind of come to grips and acknowledge and realize, like, “okay, so this was a bad idea.”

And in the poem, the person gives up and moves on. But I feel like I’ve worked on many teams where they just steam ahead anyway.

Jamie

I love that. And I feel like it’s part of a thing where perhaps more developers should read outside of their own sort of speciality, or experience outside of their speciality. Perhaps for people who don’t read, they maybe listen. Right. Because over the past two years, I’ve been consuming loads of content that’ve got nothing to do with development. In the same way that there is no way that Richard Kipling, a man who was in the First World War, could have known about computer software engineering. Right?

Scott

Right.

Jamie

No way he could have known about it. But he’s taking that same idea of the same principles we use as engineers, I suppose, and put it into an art form. Right. And I’ve been doing this thing recently where I read loads of different books that are maybe business books, maybe life advice books or whatever. And there’s always something in there that applies directly to our practice as developers, like the one I keep throwing out there because it’s quite apt to I feel like everybody is the KonMari method, which is the life changing joy of tidying up. And I’m sitting here in a room that’s completely just trashed full of stuff all over the place, right?

Scott

Same.

Jamie

But the core tenet, if you boil her advice from that 300 page book down to one sentence and it’s been said before, but if it doesn’t spark joy, throw it out or get rid of it, right? And if you replace “spark joy” with if it doesn’t do what it’s supposed to do, get rid of it. Well, that’s clean code right there. Right?

Scott

Right. Well, and I think it also touches on something that for me comes up over and over again with almost every organization that we work with and any code base that I’ve ever taken a peek at. I try to ask the question, “do you know how much of this is actually used by your customers?” A lot of organizations don’t have that knowledge.

And there are ways to find dead code that just is provably never executed. And if you have tooling like that in your ecosystem, use it and delete that code right. Because it’s not serving you, like, get rid of it. I think also instrument your systems so that you can know what features are being used. So that feature that you built to solve a problem that everyone in leadership was really excited about, there was a big push to get it out the door. There was a big launch, a lot of fanfare. How many of your customers are using it? How often does it get used? And does the level of engagement that your customer base has, is it worth keeping it around? And I think that’s very much a business decision. That’s not a decision that just random software developers should be making. It is a piece of data that leadership should know and leadership should be to make an informed decision about and say, “this piece of functionality costs us so much energy to keep working.” And even if you just come up with a guess, right, what percentage of the software supports that feature? The engineering team could probably come up with a good guess for that. And then you could make that the percentage of the budget that supports that team. And then look at how much engagement your customers are giving in that and how many new customers ever touched that feature and is it worth keeping? And if it’s not, get rid of it.

And I feel like there are too few organizations that delete things when they’re no longer serving them. So even if it’s a software system that isn’t public facing, let’s say it’s only internal. It’s internal to the business. It maybe automates the business operations and it maybe models lines of business that the organization performs. When the organization decides to stop a line of business, delete the code that supports it. I think try really hard to keep those things in sync because we don’t delete enough, I feel like there’s so much effort and so much focus on adding new features, adding new features, adding new features. And I feel like we don’t have enough conversations around deleting things.

Jamie

Perhaps we should start doing a new type of development. Deletion-driven Development: delete all the features until someone starts yelling at you and then pull them all back.

Scott

I think you certainly need to be smart about it, right, and make sure you’re not going to wreck somebody’s day or make it hard for them to get their job done. And at the same time, one of the things that can slow engineering teams down, one of the things that can make it difficult to work on a software system could be the CI/CD process. And it could be that 10% of the build time is spent validating a feature that 1% of the customer base actually uses. So that’s real time that you can compute. Is it worth having your dev team wait to make sure that that’s still working? Maybe it is. Maybe that 1% of your customer base is really important. Right. But I think that investigation at the very least needs to happen. And I think for most organizations, it’s not happening.

Jamie

Totally.

And I think that it goes into just plain business sense. I’m agreeing with everything you’re saying, but it is it’s just budgeting. It costs this much to do this thing. Are we getting a return on that investment? Yes or no? And it has to come down to that. And the only way that you can do that, I suppose, is to have metrics and logging. And whatever form that metrics and logging takes, you have to have that and you have to be able to surface that in a way that makes sense to the people that need to see it. Right?

Scott

Yeah.

Jamie

Like, for instance, if you’re perhaps surfacing this metrics and logging to the CEO of the company or the CFO of the company, somebody who makes the financial decisions and you’re showing them, well, we’ve got this entity framework exception right here and this like http response exception, right. They don’t care. What they care about is how much money am I getting back for how much money I’m putting in? And can we show that on a bar graph or a pie chart or something? And as long as the numbers are heading in the correct directions for them, they’ll be happy.

But then when it comes to that time, when they’re like, well, actually, like you said, we’ve spent a million dollars building this new feature and we’ve only seen $100,000 back. And market research suggests we’re never going to see any more than that. Is it worth cutting our losses and getting rid of it? Because like you say, there’s going to be some support deal in place where maybe it takes 25% of the engineering team to actually keep it up and running. Well, if it’s never going to make you any more money. And - I have to put this caveat at the end - And if you’re in the business of making money right then because obviously different businesses are aiming you for different things. Absolutely. If you’re aiming for making money and you’re not making money, that’s your decision right there. Right?

Scott

Yeah, absolutely. Being able to answer that question what percentage of my customers are engaging with this feature? What percentage of my customers are using this feature? I think that having an answer to that question is a cross cutting concern that people should really consider figuring out a way to design into their systems. I think a way to do it could be detailed tracing or detailed analytics. But there’s probably a whole host of ways to kind of get the answer to that question, but kind of figure out for the problem that you’re solving. What’s a good way to know and do so - I will say this as a caveat: it’s important to make sure that the ultimate customer’s privacy is respected as part of that data collection. So you don’t want the need for that information to cause other challenges. But I do think it is really useful to know in an anonymous, aggregated way how often something’s been engaged with.

A Request To You All

If you’re enjoying this show, would you mind sharing it with a colleague? Check your podcatcher for a link to show notes, which has an embedded player within it and a transcription and all that stuff, and share that link with them. I’d really appreciate it if you could indeed share the show.

But if you’d like other ways to support it, you could:

Leave a rating or review on your podcatcher of choice
- Head over to dotnetcore.show/review for ways to do that
Consider buying the show a coffee
- The BuyMeACoffee link is available on each episode’s show notes page
- This is a one-off financial support option
Become a patron
- This is a monthly subscription-based financial support option
- And a link to that is included on each episode’s show notes page as well

I would love it if you would share the show with a friend or colleague or leave a rating or review. The other options are completely up to you, and are not required at all to continue enjoying the show.

Anyway, let’s get back to it.

Jamie

I think you raised a very important point there about the anonymity of the user, not just from a person to person point of view. Right. Like, if I’m using some system, I don’t want the metrics and the logs that help their bean counters. I hate that phrase. But the person who makes that financial decision right? They don’t need to know it’s Jamie who’s checking this button. They need to know that it is a person or it might be an automated service. They need to know that something is using that service. They don’t care who. And so from a personal point of view: yes, I don’t want my information being spread to whoever just because we can. But also, there’s a regulatory consideration because I know that there are some states in the US that allow you to collect data and some states that don’t. Over here in the UK. And over in Europe yeah, we don’t allow it. The regulations for GDPR state that it has to be required for the running of the business. Right. There has to be a real business case for you to collect that data.

Scott

Right. And if you do collect it, then to maintain a person’s right to be forgotten, they need to be able to see what data you collected, and you need to give them the ability to delete it if they ask for it to be deleted. Yeah, those are all very important to comply with as you’re collecting this. And even if you’re collecting data analytics anonymously, if you’re doing so in a way that you can still recognize individuals and individual behaviour, depending on why your system gets used. So let’s say let’s think of a healthcare scenario, the usage patterns of an individual. If you’re able to drill down and see that that individual uses feature A and they use feature B right. If you’re able to see that, then that might reveal something about that individual that they might want to keep private. Right. So I think keep that in mind as well. I think that’s just part of the ethics of collecting this information and making sure that it’s done with respect to the human beings that are interacting with the systems that we build.

Jamie

Sure. In an ASP .NET Core context, I tend to just use perhaps the automatically generated request ID and maybe a correlation ID talking across microservices. Just pass this on for your logging right. So you can tell where this request came from. And that’s typically all I’ve ever needed. But I’ve never worked on I have worked on some big systems, but I haven’t worked on big systems where the metrics and the logging were desperately required. Just throw the logging in there because it’s nice to have.

Scott

Yeah. And I think for a lot of web applications, just knowing the URLs that are that are hit is going to teach you a lot. Like, even if you just know that so you don’t even know the IP addresses or anything like that. You just know this URL was accessed x number of times within a 24 hours period or one month period or something like that. For most web applications, those URL endpoints will be a close approximation to feature and will tell you a lot. And if you have URL endpoints in your system that don’t get hit in, say, a three month time period, maybe those are just never used. Maybe they’re only used at year end. Right. That’s something you have to keep in mind. But it could be that they’re just never used.

Jamie

Yeah, and that totally makes sense, too. I joined a team - at the time of recording - I joined a team about a year ago who had a web API that had 250 different endpoints. And I was like, okay, which is the priority for support? The answer was all of them. Well, that’s none of them, then.

Scott

It’s none of them.

Jamie

Yeah, right. Because I can’t physically support 250 things. Right.

Scott

Yeah.

Jamie

And I was like, well, how do we know which ones are important? Well, they’re all important. Okay, so when this was being architected, did you have a discussion with the end customer, the end client, about which ones were built first? Well, these ones. Okay, so does that mean that they are the most important ones? No, they’re just the ones that we built first. Right, okay.

How are you going to support that system if you don’t know what’s important? Right. Naturally, yes, everything is important. But like you say, if you know which endpoints are being hit the most, you could then make that decision of, well, this. One’s being hit 1000 times a minute and this one’s being hit once every two years. I think it’s safe to say that the 1000 times a minute is a little bit more higher in priority. Right?

Scott

Yes.

Jamie

When that one drops that’s 1000 requests a minute that are going to fail.

Scott

Yeah. And if you can improve performance on that one, then you’ve, you know, improved you’ve, you’ve likely done two things. If you can improve performance, you will have reduced the compete resources that are necessary. So there’s going to be a cost savings and you will have saved some time of the people who are using the system.

Jamie

And perhaps loads of money too. Because if you can improve it and everybody understands it and you’ve bolstered on some more tests and you’ve got loads of stuff around it, more logging, more metrics, more alerts perhaps, then yeah, that’s even better. Right. Because then like I said, and like you said several times, you’re then able to make the intelligent, informed decision about which things do we need to focus on. Right. Because without that, without those metrics and those logging things and without the analytics and without all of these things that we know that we all should do but very few of us actually do, like test-driven development and things like that, or even just writing tests. There’s a few people that I know directly who will chuckle exactly at that point because they know some of the troubles I’ve had in the last six months. All of these things are not just there as busy work to slow it down. It’s like those things should be best practices. Right.

Scott

Yeah. And I think when it comes to tests, I look at them for myself as I write them to convince myself that what I wrote is what I meant to write. And I think they also provide durable value to make sure that in the future it still works the way I meant it to. So I come at it from I start from a place of personal accountability. So even if I’m on a team where nobody else engages in that behaviour, I still will. Because that’s the process that I follow to convince myself that what I’ve built is what I meant to build. And if others have another mechanism for convincing themselves that what they built is what they meant to build, then okay. And then whether or not they find value in tests, automated tests, as kind of a durable artifact of what we meant, and whether or not something is working correctly, I think that’s a reasonable debate that people can have as well. If me writing test gets me kicked off the team, that gets me kicked off the team, I’m getting rid of them.

Jamie

Yeah, right. You may get kicked off the team, but then the code that you’ve written has a bunch of other stuff that can be run to prove that the code you wrote does what it needs to do. So even by kicking you off the team, they’ve made the software better.

I like it. So then you see, that’s my thing. The only way that you can manage the code that exists, whether it’s legacy code, tech debt, or things that you’re writing, the only way that you can effectively manage it, either as a person or as a team, is to know what’s there is, to know how it’s being used, to know how often it’s being used. And then you can make that decision. When somebody reports like, this is a P1 bug, with this piece of functionality, you can then turn around and go, it’s a P1 bug, but it’s only ever been used by three people since we released it four years ago. Is it really that big of a priority? Right

Scott

Yeah.

Jamie

And I think it’s well within our purview as developers to be able to, if we have that data, present that data and say, totally, this is a P One bug, but also we can see nobody’s done it, nobody’s using this area. That might be because it’s not been released yet, or that might be because it’s maybe been deprecated. But then if it’s been deprecated and a bug has been reported, then clearly it’s not been deprecated, right?

Scott

Yes, absolutely.

Jamie

Okay. I was wondering if you have any top tips for someone who inherits a legacy code base. Like, let’s say I joined a team and there’s a code base that we’ve decided with our descriptions together is a legacy code base. It’s not necessarily old, just very hard to change. There’s perhaps no metrics, no logging. There’s all these things in place. What do I do as a new person on that team to handle the stress that everyone seems to have already handled? They’re all meditating and saying, woosaah in the corner to be able to deal with it. How do I join them in that nirvana of not worrying?

Scott

Sometimes I don’t know that you should join them in that nirvana of not worrying, because I think sometimes there’s value in somebody with a fresh set of eyes joining the team. Because I think like the metaphor of the frog and a pot of boiling water. Right? So it’s like the people who are on the team, they got to experience the water temperature increasingly slowly over time, and that new person is dropped in fresh and is like, “ouch, this is hot.” What are the rest of you doing? That can be a valuable perspective to have. And so I think sometimes speaking up and sharing that and sharing why you think something’s frustrated can be useful, I think, especially if you’re willing to put some energy behind making it better. So I think that can go a long way.

I think on some of these ageing projects, one of the ways that can show up is with the age of the tooling. I think I’ve noticed over the years that there are situations where old tools get accepted as just this is the tool that was used when the project was built. And so this is the version of the tool we’ll continue using. So whether it’s like, I don’t know, you’re having to keep, you know, Visual Studio 2012 or whatever, and that’s the version that we install, and that’s the version that we want to run. And everybody’s working off of Windows 95 VMs or whatnot, or Windows 7 VMs or what have you, and they’ve gotten used to putting up with it, and maybe they’ve created some automation around that to make it easier, easier to work with. Finding a way to upgrade those things I think is really beneficial.

And I liken that to if I inherited a house that was 100 years old and I wanted to make some improvements to it, I wouldn’t go to the hardware store and ask the person behind the counter where the 100 year old tools are, right? I would just go buy some tools and like, and it would be the modern tools, and that’s what I would work with. Like, you know, so if I, you know, let’s say it was a house that was built in the 1600s I’m, you know, I’m not going to go to the blacksmith and ask them to make me some nails. I’m just going to buy a box of nails. I think using modern tools and finding ways to use modern tools, even if it is an ageing project, can yield a lot of benefits. And I think that the same is true for modern techniques. And I think there have been a lot of improvements to kind of ideas around automated testing and different ways to do automated testing. And so a lot of that tooling can be embraced on ageing projects as well.

So if you’re in the Microsoft ecosystem or Microsoft adjacent ecosystem and you’re working on a web project, check out Playwright and Playwright .NET. And that is a really nice tool for creating automated web-driven tests that interact with your application from the UI. And you could probably create a fair bit of test coverage pretty quickly by just creating one of those that logs into your app and clicks a button. And that could be a great smoke test. Even if you don’t have any tests at all, that can be a great smoke test that can build some confidence for you to make some more foundational changes in the future.

Jamie

Okay, so how would I go about learning about these tools then, right? Because let’s say I’m someone who’s, earlier in my career, you and I feel like we’re of a similar vintage. I like to use that word rather than say, “hey, people are old. We’re vintage,” right? We’re of a certain vintage, a certain generation, and we have the experience of just like, “oh cool, there’s this tool that somebody’s told me about,” right? Is it just waiting for someone like Scott to come along and tell me, hey, playwright.net exists or should I be spending time in my downtime looking these things up? The topic before the world went wobbly, we all used to go to meetups, right? Is the topic of going back to meetups or going virtually to meetups and exchanging these bits of information and learning from other people? Is that the best way to do it? What would you, what would you say?

Scott

I think I’m going to give you an independence answer because I’m a consultant and that’s what consultants do. But and of course my dog’s barking.

Jamie

He knows you’re talking.

Scott

Hush, hush, hush, hush, hush.

My father in law’s over and mowing our grass and she’s barking at him.

Jamie

He’s like, “oh no. The house is under attack.”

Scott

I think it’s important to look at how you like to learn and find resources that match the way you like to learn. So the recommendations that I’m going to have are biased by the way that I like to learn. I like to learn by reading. I’m not a big fan of watching videos. I don’t listen to a lot of podcasts either, even though I host one, which is I’m not supposed to say that. So for me I read a lot. So I have an RSS feed reader application and I subscribe to a lot of different RSS feeds.

For .NET, I subscribe to the master list of all the Microsoft Dev Blogs. I think those are a great resource. You get to find out what’s new in the Microsoft ecosystem in general. InfoQ also usually has really good articles, not just about the donate ecosystem, about others, because sometimes you’ll learn about a technique in another ecosystem outside of the one you’re currently working with and you can discover a way to use that tool even though it’s outside your language ecosystem. So even though you’re building something in .NET, there might still be a way for you to utilize a tool that was in Java because it’s helping solve a problem in a neat way. And so paying attention to what’s going on in other communities is what I do. The Change Log podcast, they also have a blog, an RSS feed that you can subscribe to where like, cool projects that they’ve noticed and they come across, get mentioned and they have an email newsletter that does the same thing. So I learn about neat little projects and the little tools that way.

I also will usually about once a week I’ll open up the GitHub mobile app on my phone and go to the Explore section and just look at what’s trending and why. Why are these projects trending? Are any of them of interest to me and what I’ve got going on or any of them kind of useful things for me to file away?

I’ll also probably, I don’t know, once a quarter I’ll go and there are projects on GitHub that are like awesome blank. So there’s awesome .NET Core, there’s awesome Web, there’s awesome React, there’s even awesome awesome, which is like an awesome list of awesome lists. But the idea behind these awesome lists is that it’s pretty much just a list of links and some of them are organized by topic and you can find and learn about interesting things that way.

I think you could even go to NuGet and look at some of the analytics for the more popular NuGet packages. And what do they do? Why would people use them? Might I be able to make use of them one day, if not now? I think taking the time to kind of do that exploration and kind of just be aware of what’s in your ecosystem can be a really good benefit.

And matching a way to receive that data, being able to match that with the way that you’d like to learn would be absolutely best. So maybe there’s somebody who puts out a video, video series that you can watch that will let you know that if you like to consume videos or you may be listening to a podcast. But I think that’s how I stay up to at least I feel like up to date.

Although at the same time, I discovered a new way to do something just like two or three weeks ago.

It’s a pact.io, and it’s a contract based testing for HTTP client and server relationships. And if you use their tooling and follow their technique, you don’t really need to write an integration test. You can write two unit tests and you’ve done the same thing because the one unit test defines a contract and that contract is used in the other unit test to make sure that the server complies with the contract. And it’s like, that’s brilliant. And this project has been around for like eight years and I just now discovered it. Every now and then you’ll stumble across something that’s new and it’s like, I really like this approach. And when you find those things, figure out a way to use them. If you have an intuition that something might work, try and experiment, see if it will. I think that’s another thing is being willing to try and be willing to fail. That’s a big part of it.

Jamie

I like it. I like that you mentioned RSS feeds, trending and analytics, right? Because all the way back to what we’ve to talk about earlier, right? Because then how else can we find out what other people are using if those metrics weren’t there? Right? Metrics are there. We’re using them on a daily basis. Twitter is a metrics thing. That’s what it does. It provides you with metrics on the topics that you’re interested in.

No, I like it. I’m on the back of you discovering something and starting to use it. I’m a big fan of sort of internal hackathons and I’m a contractor myself, right? So I’m not internal, but telling people, “hey, you should just grab a random NuGet package or grab a random library or something and see what you can do with it. And then once you’re done, have everyone do a 30 second long stand up.” And maybe not everyone’s as confident and extroverted, but maybe have them do some kind of report that is short five sentences, 30 seconds long. This is what I did, this is how it works. And I wonder if this is useful to us. Right?

Scott

Yeah.

Jamie

I just have everyone pick a random library and see what they can build with it. And even if they can’t build something with it, that’s a positive, right? Exactly. That might mean that the library is no good or that you need other things to go with it. Right. So, yeah, totally agree with you there. Absolutely.

So Scott, as we start to sort of wrap up, I was wondering, could you perhaps remind everyone about Legacy Code Rocks and the different projects that you’re working on and stuff that’s going on so that people can go, “you know, this Scott, he’s amazing. Let’s go find out all about him.”

Scott

Yeah, sure. So there’s Legacy Code Rocks is where you can find information about the podcast. You can also find instructions for how to join the Slack Workspace. It’s pretty easy. You just go to slack.legacycode.rocks and then sign up from there. And then there’s a channel on Slack called Virtual Meetup where you can get the link to join the Virtual Meetup and it’s at 1PM Wednesdays. And I often joke that it’s like a support group for folks who are working with legacy systems. If you’re looking to commiserate with others and learn from them, that’s a great, great place to do that.

So those are things we’ve got going on. And then there’s Corgi Bytes. We’ve got clients that we’re currently working with. And then we’re also working on a tool that’s actually primarily built in .NET. Probably I’ll upgrade to .NET seven as soon as it comes out. We’re talking .NET6 at the moment. And it’s for kind of analysing dependency freshness as a metric and giving teams insight into just how out of date their third party dependencies are. I have a hypothesis that if that’s a metric and a piece of data, that if it were more visible to business leaders, that they would put budget behind keeping things up updated and keeping things upgraded. So that’s kind of the purpose of that tool that we’re working on.

We’re developing it with an open core model so the CLI is an open source project that people can check out and then all of the nice, easy to consume, easy on the eyes reports are going to be on the closed source website and eventually we’ll try to monetize accessing those reports. But for now it’s pretty open. So you can go to freshli.app to try out what we’ve got so far. You can type in the URL of a GitHub project and see how out of date its dependencies are, if we support that language ecosystem. And then you can also head over to github.com/corgibytes/freshli and see a list of all the related projects that we have going on in GitHub and there’s several that are tied together. The architecture is kind of fun. I like geeking out over it. That’s something that we’ve been working on. I think keeping dependencies up to date is important and I think if it were easier to tell very similar to what we were talking about earlier, right? If it were easy to tell what features are getting used, it’s a similar challenge. But if it were easier to tell just how out of date I am with these libraries that I’m using, then maybe I would keep them up to date.

Jamie

I like it. I like it because just peeking behind the curtains, there is an insider baseball. That was originally what we were going to talk about, but I think I took us on a completely different direction.

Scott

I let you get to the end.

Jamie

I feel like it’s a great sort of introduction to the software, right. So perhaps if you’re available and I hate to do this in the recording, right, because it feels like it puts you on the spot, but perhaps we can come back for a part two and talk about Freshly and enjoy that. Because then it’s like, here’s the theory as to why you should do it and here’s how you could do it.

Scott

Yeah, happy to do a part two if you’re open to that.

Jamie

Yeah. Awesome. Well, listeners, make sure you tune in for that, for goodness sake, and definitely go check out Legacy Code Rocks, because, like I say, I’m a fan and it’s a really great show, so you should definitely go check that out. I guess all that really remains to say, Scott, is thank you ever so much for spending this time and being a bit presumptuous. Some more time with us. Another time to talk about Freshli.

Scott

Be happy to do that. Yeah. Thanks for having me, Jamie. It’s always nice to be kind of on this side of the interview, if that makes sense. Like, as somebody who does an interview style podcast, I don’t often get to be on this side, so it’s nice. Thanks for the opportunity.

Wrapping Up

That was my interview with M. Scott Ford - hopefully one of two. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at dotnetcore.show, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/review for ways to do that - reach out via our contact page, and to come back next time for more .NET goodness.

I will see you again real soon. See you later folks.