PostHole
Compose
Login
SE Radio 587: M. Scott Ford on Managing Dependency Freshness
M. Scott Ford, the CTO of Corgibytes and host of the Legacy Code Rocks podcast, discusses managing dependency freshness. SE Radio's Sam Taggart speaks with him about why dependency freshness is important to ensure that your code has all the latest bug fixes, how exactly to measure dependency freshness, and some of the insights that teams can gain from monitoring freshness over time. Brought to you by IEEE Computer Society and IEEE Software Magazine.
M. Scott Ford, the CTO of Corgibytes and host of the Legacy Code Rocks podcast, discusses managing dependency freshness. SE Radio’s Sam Taggart speaks with him about why dependency freshness is important to ensure that your code has all the latest bug fixes, how exactly to measure dependency freshness, and some of the insights that teams can gain from monitoring freshness over time. Brought to you by IEEE Computer Society and IEEE Software Magazine.
Show Notes
Related Episodes
Other Resources
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Sam Taggart 00:00:18 For Software Engineering Radio. This is Sam Taggart. I am here today with M. Scott Ford. Scott is the co-founder and CTO of Corgibytes. He regularly conducts training courses on O’Reilly’s learning platform in LinkedIn Learning. Scott is the host of the podcast, Legacy Code Rocks and manages their Slack group, which I’m a part of. That is how I met Scott. Scott is here to talk to us today about a tool he has built to manage dependency freshness. So first of all, Scott, let’s talk about defining dependencies. What do you mean by the word “dependencies”?
M. Scott Ford 00:00:51 Yeah, so I think in general it’s best to think of it as code that you didn’t write that you’re pulling into your application from somewhere else.
Sam Taggart 00:00:58 So how are you typically pulling that code in? Is it through a package manager or both?
M. Scott Ford 00:01:02 It’s varied across history of programming. So I think in the days of yore, it would’ve been like copy and pasting from another source or copying a file into your project directly or buying a third party product that had to be installed into your system with an installer. So there are like DLLs that were installed that way. And then also in some ecosystems those pieces of code that you’re consuming from elsewhere are either part of the operating system or can be installed with an operating system package manager. But for most modern programming language environments, there is some kind of dependency manifest file that allows you to specify the packages and libraries that you’re depending on and optionally what versions of, of each of those libraries you want to consume.
Sam Taggart 00:01:53 So you mentioned versioning plays a very important role in managing freshness. So can you talk a little bit about that?
M. Scott Ford 00:02:00 So freshness, there are multiple ways to define it. First, let me take a step back and say that the term dependency freshness was introduced in a paper by Joel Cox et al. I forget the name of the paper, but the idea is how out of date the version you’re using is, and there’s different ways to measure how it’s out of date. So you can look at the version number and you can compare components of the version number that you’re using to components of a later version number and get a distance between the version you’re using and another version. Whether it’s the latest version or the latest for the series that you’re targeting or whatnot. The metric that I like the most is one that’s called libyear and it’s also referred to in the paper as a time-based kind of temporal distance. So it’s looking at the release date of the version of the package you’re on and comparing that with the release date of the latest version. And you get a distance in years. And so if it’s been six months between the version that you’re using and the release date of the latest version, then the libyear for that package will be 0.5, because half a year being six months.
Sam Taggart 00:03:20 Now I see that giving some problems because certain projects have more churn or are releasing more often than others. There’s probably some projects that are stable and only get revised once a year or something when they find a bug versus projects that maybe are in development or are constantly churning out new versions. Is there a way to account for that or this method just doesn’t take that into account?
M. Scott Ford 00:03:42 Unfortunately this method doesn’t take that into account. There are some of the other freshness measures if you key them to stay on the major version that you’re on, but you want to make sure that you are always on the latest minor version. You can look at distance measures that will help you compute that, but Libyear just on its surface is always comparing against the latest. So that is a little bit of a weakness in that. Another weakness is that freshness doesn’t really communicate quality of the dependency itself. So there are other factors to consider as well. Such as is the package that you’re using still being updated by community support or a vendor or has it been abandoned? So you might be on the latest version so your dependency freshness score would look really good because you’re on the latest version, but that version is eight years old or something like that.
M. Scott Ford 00:04:47 And that’s not necessarily a bad thing. Like you said, it could be really stable, it could be just an easy to understand problem. The things that it depends on don’t change often. So it doesn’t have a need to change. Or it could be that there’s just not any more work on it and it’s not receiving bug fixes, it’s not receiving security updates, it’s not getting operating system updates to support newer environments or newer processor architectures. Those are also possibilities. So I think, sometimes these things warrant investigation and I think there are different trends that you can start to look for and you can start to spot. So if you’ve got a dependency that you’re on the latest version, but that version’s more than five years old or four years old or three years old, whatever your threshold might be, maybe it warrants investigating. Has the community abandoned that package and is it time to look for an alternative? So I think there are signals that will start to show up in the data that you can look for and then start to use those as targets for further investigation.
Sam Taggart 00:05:52 So I think this brings us to a very important question, which is why is dependency freshness important? What possible things have you seen go wrong when dependencies are old and out of date?
M. Scott Ford 00:06:04 It shows up in three different ways. There’s three factors, and depending on your organization, each of these factors will have a varying degree of importance. One is staff turnover. So most teams that I’ve worked on, the developers on that team get frustrated when they have to work with libraries that are consistently out of date. It becomes a productivity challenge as well. That’s the second factor. Keeping with that first factor, as people get more and more frustrated, they will eventually not want to work on the project anymore and then look for a job elsewhere. So that is a factor and it is a very real factor for some teams, especially when there are lots of opportunities for software developers to seek other forms of employment at other organizations. That can be a really big challenge for teams managing turnover. And so I think it does create a little bit of turnover risk.
[...]
📄 icse15.pdf