Episode 112 - NDepend with Patrick Smacchia

The first thing I want to say, Patrick, is thank you ever so much for spending part of your, I guess, early evening. I mean, this is the podcast time machine Weebly Wobbleness, so it won’t be early evening for some when they listen to it, but for you right now as we’re recording, it’s the early evening. So thank you very much.

You’re welcome. Thanks for inviting me.

Excellent. Well, you’re very welcome, very welcome. Yeah. I always really appreciate it when people take some time out to discuss things on the show, whether it’s a product that them and their team are working on or whether it’s an individual person coming on and sharing some advice. In all instances, I think it’s great just to sort of share that knowledge. Right? So I want to thank you in advance for the knowledge and experience you’re about to share. So thank you for that.

You’re welcome.

Brilliant. Okay, so first things first, I guess, would you mind telling the listeners a little bit about yourself, a little bit of your background, maybe the kind of stuff that you and your team are working on at the moment, just so they get a flavour for who you are.

So my name is Patrick Smacchia. I am French, as you can hear; 47 years old. I’m in programming for literally I started ten on Avid computers, so it’s like 35 plus years ago. I graduated in IT and programming and mathematics, which I liked a lot. And as many I started as a consultant, a junior consultant in a very large corps. It was very interesting because I learned a lot. This is a great way to start in a large corporation to learn, because these guys always are the expert of programming people, you can talk with them, which are interesting, and generally they are very nice to junior. So I learnt really a lot about professional programming because of course I was a hobbyist before and a student.

I did a few large bank and there is a lot of IT in these guys and also some iOS speciaal I did a few large company and very recurring problem they had and they still have these guys they have very large legacy. Like for example by now .NET is more than 20 years old so some company have some 20 years old legacy to cope with; enormous with dozens of people, a lot of turnover, millions of line of code. And what I noticed is that they are a real problem understanding what’s happening, what was happening they are the real problem to making it evolve they have a lot of very large monolithic piece of code, some untested code. So I’m sure to the professional developer listening to me that I talk to them because this is how software is happening because nobody… no environment is really perfect you cannot control the turnover et cetera.

So in a world almost everyone has a problem with code quality and at the point came to me the idea to try to build a tool it was not the idea to make a professional tool at all it was just an open source project hobby which I called nDepend, which started in 2004 - in April 2004. And at first I was interested in Robert Cecil Martin code metyri - so for those who don’t know maybe you know him as Uncle Bob So he’s a famous figure in our industry that wrote very interesting books. So Robert Martin did created some interesting metrics about understanding how companies should interact especially he is also at the seed of SOLID principles. So all this was very interesting and what was really interesting is that you can compute metrics from the source code.

So at that time it was kind of innovative reflection and actually at first I used reflection, .NET reflection to get some information from the code. So it was just released as an open source project it was interesting for me to use it in my professional environment as a consultant; it was interesting to try to see where things could be improved. And I put it on the web and then I figured out that a lot of developers were in need of such tooling; and a lot of people were talking to me, “I would like this feature,” “I would like this feature,” et cetera, et cetera.

So came to me the idea to create a business out of it, mostly to be almost 100% on it. Because it was very interesting all this year because the thing is that you don’t cut that much when you are a junior you are learning a lot, you are fixing bugds et cetera, but you are not creating. So it was a bit frustrating for me it was no question that I would be happy, more happy doing my project the way I want. Exactly in the condition I want.

So nDepend started to be a professional tool in 2007, and since then, like, thousands of clients registered and the team grew and sorts of things are evolving. And what is extremely evolving a lot is .NET. So every tool vendor around like JetBrains people and others, we are working hard to cope with the Microsoft reason because for a long time the .NET Framework was slightly evolving. But suddenly I think in 2016-17 they start to move everything on the .NET Core platform and also the language team are doing amazing thing in creating new version of C# pretty every year. So I have to say it’s a bit hard to run after all this. It’s challenging but it’s also rewarding and it’s interesting for us because this is also a condition to make the net platform grow all this new stuff. Today I think we can say that C# is at the top of what you can expect in 2022 in terms of [an] object oriented language, and same for the .NET platform. So I don’t complain. I don’t complain. More and more projects are started in .NET which means also more user for us, which is very good. So yeah, this is a very great time to work hard on .NET and to be part of it and as the last almost 20 years I’m on it and maybe also when did you start .NET?

Oh my goodness, I started working with .NET in 2004, so almost 20 years, right? A few years before.

Actually, something I didn’t mention that was very interesting is that I had also a passion for training and I had the chance to write the best sold in C# and .NET. And actually it was released in 2003. So at the very beginning and this was extremely an extreme way to really learn .NET it’s 1000 page book with more than 600 sample. So I learned so much on the platform. So this allowed me, when I started the tool, to have a 360 view on the platform, on the language and it was extremely helpful. But unfortunately it was very interesting to write. But at the point I had to choose between my own tool and my own book. So I choose the tool. But maybe today the book would be like 3000 page but I know there are some excellent C# book[s] out there.

Yeah, you see all of the things you’ve mentioned there, there’s a lot going on, right. But what I really like is that nDepend or where it started, it started as like an open source hobby project, right? And I’m not trying to reduce that at all. What I’m saying is it’s great that it started there because when people come to me, when juniors come to me or people come to me and say, “hey, I want to get better at development, I want to be a better how do I level up, how do I get better at doing this?” And I say to them well, “find a problem or a thing that you want to solve in your own time and see if you can digitize it.” And I feel like Patrick, you’d identified that corner case and you’ve gone, “you know what, I can do this.” And you then said you used it as part of your consultancy. So then you could turn to your clients and say, “hey, look, this is some verifiable truth, some code that I can run against your code and tell you where the problems are, tell you what the issue is, tell you to focus your efforts in this area.” And I feel like there’s a lot to be said about that, I think.

Yeah, sure, indeed. It’s a kind of organic way to do things, especially when you’re junior. Something a junior must keep in mind is that it’s really the right time to try things because maybe you’re not in debt, maybe you don’t have kids yet, maybe so you can really organize your time the way you want. If you want to work at night, if you want to work during the weekend or whatever. It’s really a great way because definitely now we are put on point, like all of us, to be an excellent father. So it’s not very compatible to spend so much time with your kids and maybe do all your hobby projects and work out. So when you’re still junior, it’s really the right time to try to do things, not necessarily to have in mind to create a project or make a business or whatever, but just to progress. Maybe you can create a business later, but it has to be organic. You must go first. All the steps the industry went through during the last 20 years, or maybe even 30 years. It won’t take you 30 years, because now you have to go through this.

So concerning nDepend we were talking. It’s a static analyzer, so it’s a .NET static analyzer. And I have to say that something very big happened in the middle. I mean big in the static analysis. in.NET it’s the Roslyn compiler that reach ga in Visual Studio 2015.

Okay, so basically I assume everybody knows what is Roslyn. So basically it’s an open source compiler, for C# proposed by Microsoft. And they were smart enough to introduce in it the analysis part. So basically all the warning you get when you are compiling, they give you the possibility to generate your own warning. So by writing your own rule, which is of course excellent. So Microsoft proposes hundreds of rules and they are the tools with their own rules. And there is also the Resharpoer engine, which is very good. And then there is the nDepend engine, which is different, which is not based on Roslyn and hopefully for nDepend there is room for it because it does things differently. So basically nDepend is scanning your code so everything you give it to him it can be source code, DLL, PDB code coverage data, everything. So you try to analyze everything and create a snapshot view of your code base. And then the idea is that a rule is a query against the snapshot. Okay? So you can create query. There are like 200 queries by default.

So what’s interesting is that in this snapshot, contrary to Roslyn, you have very high level way to approach very high level to approach dependency. For example, if you want to know dependency between a type and a namespace or if you want to know also code coverage or so nDepend can compare to snapshot. For example, a query we run every day on nDepend for example, “is telling me the classes that were 100% tested, covered by test and that are not any more 100%,” which is not something that could be easy with Roslyn but it’s extremely easy with NDP.

This is the kind of stuff nDepend does very well and also all the finding all the entangling code: “tell me which monolithic part of where can I find all the monolithic stuff and also give me advices on what can I do to try to make it a bit more componentized.” I like this one to levelize things. I mean to have a top down approach and not everything not a big ball of mud but just a nice, directed graph. Okay, so did this kind of thing nDepend also for example, when you compare you want things like API breaking change for example. So tell me what used to be public that is not public anymore or tell me the interfaces that change it because maybe my user implementing it and then they’re going to be broken or all this stuff. Also some naming. So of course we have tons of naming conventions but it’s very easy with nDepend to create your own naming convention because actually what I did not say is that query is a C# inquiry because the model exposed by nDepend from the snapshot is of course a /NET API model. So you can query query it.

And also something that makes it different is that it’s very, very fast. Because nDepend is by no means better. But that was in is different because everything I said would take time to unwind. Because on a very large application with like 10,000 source files, maybe it will take a few minutes. And nDepend, it would take a few seconds because nDepend doesn’t store in his model. All the very tiny details you get in Roslyn.

So Roslyn is excellent at doing things like maybe this prereference will be new so maybe you should do something about it or maybe you’re going to fix that kind of exception here. So Rosen is excellent at finding bird or maybe this line is not needed anymore, et cetera. These things are not approached by nDepend but instead the other thing. So that’s why the tools are kind of complementary and actually we use it in our own shop bus approach with success. This is very interesting to be able to scan very large code base very quickly to not lose time. This is something extremely important when you’re developer to not lose time. This is why you need the best IDE - which can be discussed actually - this is why you need the best hardware; and recently I wrote a blog post about how to make your visual studio build faster. So that’s interesting because there are quite a few things that can be done there are also some extension to visualize your build. So all this to say that don’t lose your time, okay? If you want to have that kind of advice. I talked about nDepend earlier, quickly, in a matter of seconds and inside your IDE, then you can try nDepend and it can be very fast on it, but you won’t get all the tiny detail that you get with Resharper and Roslyn. I have to say they are very good because typically as a developer, you only work with one or a few subset of source code. So for those NGI, they are very good at this subset because this is the one you get in front of you. Why do they nDepend will get more 10,000ft view of problems.

Something also that makes it very very different is that there are two things there are technical debt estimation, okay, and there is a focus on new problem. So I think both are very interesting. So first, for the focus on the new problem, as I said earlier, the snapshot are compared nDepend. Compare it so it can run all the rules on it. And so it knows the issue that were introduced between the snapshot, the issues that were fixed and then now that were interesting because typically it’s when you are changing your code that you are introducing new problems and nDepend, live inside your IDE, will tell you about this very new problem. Because when you run a static analyzer or the large code base, you will get literally thousands of issue. Any Resharper, Roslyn, and nDepend, you will get thousands of issue. But typically, you will edit. Maybe in a day, maybe like 15. Source Five, you will introduce some new mistakes. And this is the one you should fix now before going back, before leaving work. This is the one to fix/adapt.

So this introduces a kind of priority in the issue and nDepend brings you that while other engine you open the source code. And it’s very good at showing you the problems in the actual source code, but you have no idea if the problem are new, so it’s hard to prioritize. So of course you can say as soon as I open the source fire we fix everything but this is not practicable so something needs to be prioritized - sorry for the accent.

And the second thing is about technical debt estimation. So technical debt is an analogy. It’s an analogy with the financial debt. So typically, we work hard. We want to quickly get the job done, but at the end of the day, you will get all this little problem could be monolithic, could be untested code, all this stuff. And this is what Fowler called technical debt because you introduce some debt in your code and as every debt, you need to be reimbursed. Because if it’s not reimbursed, which means you don’t care for code quality, you will end up with poor quality code. And the problem with poor quality code is that it’s hardly maintainable. So here we are in the maintainability side, and we all worked now in the past on fully maintainable code and we all know how such a nightmare it is to fix [a] bug, to add new feature here we are typically on the problem I mentioned I saw in very large corporation they all have or windows very large code base with tons of technical debt. So the idea is that technical debt, you can put a number on this debt, so you can put an estimation.

Because as everybody knows, if you cannot measure it, you cannot make a progress on it. So first you need to measure. So the right way to measure the technical debt is the human time to fix it. Okay. So it nDepoend attempts to put an estimation for each issue there are a few other tools that are doing it. What makes nDepend different is that because the rule is a C# LINQ query then the technical debt estimation is just a formula. You can put a formula in your LINQ query. So for example, I give it as an example you have a method or a class that is not 100% covered that you’d like to cover it 100%. So nDepend is going to have a look at the size of the class. It’s going to have a look at the complexity of the size in terms of if, case, switch, et cetera else all this stuff. So he’s going to analyze all these steps which is called psychrometric complexity and he will look what is covered, what is not covered, he’s going to look at what are you calling? Because if you are calling interfaces this is easier to mock than if you are calling, for example, some implementation. So you’re going to look at everything and try to infer formal formula an amount of time you will have to put to write tests and that’s satisfied that several users are happy with this kind of estimation. For example, for the rule that you should test your code you can get an estimation like to test this class maybe you’re going to spend 3 hours or three days and then the manager can also do the math to try to compute an amount of spend in terms of Dollar, or Euro, or GDP. So there are conversion also in nDepend to help the manager. So this worked quite well and this is an interesting way to measure how close you are to perfect quality to the modern way or at least in terms of nDepend rules.

So yeah, I think it was interesting to really compare what nDepend compared to Roslyn because everybody is working in Roslyn and not everybody is using nDepend. So I think you get a point of what makes it different.

I like the fact that it’s not just a tool for developers. You were saying there about how you could use it to produce the data for a project manager for the decision maker, say, “look, we need to deal with this problem. If we deal with it now, it will take this much effort,” and then they can say, “okay, do we have time or money in the budget to be able to deal with that?”

Because that’s a difficult thing. I always worry when I’m talking to clients, customers, users, whatever. When I say, “yeah, I can fix it, but it will take this long,” or when I say, “hey, I’ve done this. I’ve implemented this feature, but I’ve had to accumulate a bunch of tech debt along the way.” Because to non developers, tech debt is one of those esoteric things, right? Look, you’ve done it, right? If you haven’t done it properly, then why have you said you’ve done it? Whereas people who aren’t perhaps developers or haven’t come from that area, that direction, they maybe don’t know that sometimes you have to do things cut corners, I guess. Maybe cut corners is the wrong phrase, but you have to do things in a way in which you need to remember we’ve got to come back, we’ve got to fix this. Or like you said, maybe there’s some code that is just fragile, right?

Fragile.

Yeah, if you hit it too many times it will fall over and knowing that they exist, but also being able to go to the people who make the decisions and go, “here are some numbers, make the decision.” I really like that because like I say, I often worry that when I say to someone, “yeah, it’s fragile, it’ll take two days to fix,” and they’re like, “where are you pulling these numbers from?“That’s what I worry about.

And also what I would like to say, as I mentioned earlier nDepend doesn’t necessarily does everything like all this tiny little thing, it doesn’t try to find that. But actually we have in mind to import the Roslyn issue into our models or whatever the Roslyn rules so we will get more understanding of the technical debt, more precise understanding. But what I mean is that this high level view nDepend to infer from the code base itself. To me this is really what creates the real problem. If you have a null reference, okay, you will fix it to write a test and maybe you have two or three, et cetera, then you learn how to not have it anymore, et cetera, with the C# stuff, et cetera. But if you have a very large code base where dependency I’ve never been summoned when nobody really took the time at a point to think about how things should depend on each other. And typically this is a very interesting time because everyone, almost everyone are migrating the very big legacy from .NET framework to .NET Core - I mean .NET 6, .NET 7, etc. And then and and we are no exception. At nDepend we are doing that. We already produced reports on Linux and MacOS, so we are already there. But now we have all the IDE integration and also all the graphical stuff that mentioned yet. So we are working on that actually presently and we can see how the new constraints are impacting the dependency approach. For example, during like twelve years, okay, we have WinForm, we have the WPF, everything can depend on it. We got it for granted. So it was not so much.

Okay, we have a UI project which most of dependency goes to the value WPF. But now that we are migrating the UI, that in two steps. First, the UI will work on WinForm and the WPF on the .NET 7 or 9 or whatever desktop. And second we’ll use a new technology, but for that we have to wait until Microsoft took a decision to adopt a technology. So we don’t know which technology yet. So this is a multiphase migration and then we can see, and everybody can see that the maintainability of the software is really coupled with the dependency. If you depend largely on this and suddenly you cannot depend on this anymore. For example, WinForm and WPF are not working on MacOS and you want to work to work on MacOS or even in the browser. But then this is where hey, the assumption I had about dependency earlier are not valid anymore.

So one advice about this migration we figure out that .NET Standard is actually very actually our main target. Our main target is to get as much gone. And I mean, we end up with 90% of con compatible against .NET standard 2.0, which means that there are a lot of new fancy classes like DateOnly, TimeOnly or whatever. The new fancy classes in the nDepend premier, we can live with that or we can even embed it because they are open source. But what I mean is that we are restricting us on this because we don’t know exactly what the suture we build meant. We don’t know maybe if nDepend will run in a browser like five years from now or whatever.

So now we choose that to have most of our code and when I say, “most of our code,” it’s also the third party code will depend on for example we are using monosyside to analyze the bytecon, the Ielcon and hopefully monoch side is compatible about the .NET Standard. So typically we want all our code to be compatible with .NET standard which is another way to see the clean code phenomenon which is another term coined still by Uncle Bob, the guy I mentioned at the beginning. So the idea is really look at your dependency. So what Uncle Bob say? It’s about the domain. Really your domain should depend on no infrastructure. So you don’t want database in your model, you don’t want UI, you don’t want network access or whatever, you don’t want all of this, you don’t want any infrastructure. So I see the idea of depending on the .NET Standard 2.0 is exactly the same, no infrastructure or almost no actually you have the older five system et cetera underneath standard, but then also the network. But it’s a way to really restrict your dependency in a way to be really maintainable in the future. Even though Microsoft has a very solid direction, seven, upcoming eight, nine, et cetera. I guess it’s here for good, it’s here to stay. But at a point in our business, in your business it would be interesting to add your project to run, I don’t know, I don’t know something here. It’s very interesting, important for us to control our dependency and this is what we’re actually doing now and we are preparing the future for that.

I like it.

Sorry, which I did not say. Is that the .NET Ssandard. Of course you can also run on the .NET Framework, you can run on .NET Core, you can run on .NET 6. Maybe it was implicit in what I was saying, but whatever the client wants. So for example, he has a raw Windows machine with no installation nDepend will work as zero things to install on it. But maybe on a Mac machine he. Wants something else.

I like it. Yeah, the original promise of .NET Standard is finally coming to fruition right now that we’ve got this like this standard layout for libraries and things. The standard set of APIs that are supported on all of the runtimes. I absolutely love it because it allows you to do things like that. Like you said, if you build against the .NET standard, then it’s guaranteed to run anywhere.

Anywhere 90% of our record. Which means that whatever will happen, we will adapt, we will adapt to it. And also something very important is to control the third party components you are using. As I say so typically you want them to be .NET Standard, you want them to be open source and you want them to be not too big. Or at least if they are big, it means that you are using almost upon each surface. Because for example, we use the UI, very big UI component. But we were using like 5% of it. It didn’t make any sense. Just at the point we took a few months and discarded and did it ourselves and find also some GitHub component which suits well our needs. But yeah, the dependency is actually the nDepend name. So to me, dependency software is dependency. I mean, if you want to do good software, you need to really care about your dependency. And this is why I created nDepend at the beginning.

Yeah, the example that I give to people when they talk about bringing in this small dependency because, “I wanted to do this one thing.” Five, six years ago, if you wanted to deserialize JSON, everyone would just pull in NewtonSoft.Json and use that one API method, Deserialize<T> Right? But what they didn’t realize, because it wasn’t really highlighted to people until Blazor became a thing, that NewtonSoft.Json is almost twelve megabytes of NuGet packages. Right?

This is exactly what I mentioned here.

So you’re pulling in twelve megabytes of C# code just to rely just one method. Right? And you’re absolutely right. You need to know what’s in those dependencies, regardless of whether you’re open source or closed source or whatever. I like that bit of advice and I like the idea that you’ve said that there’s a bytecode analyzer as well. So let’s say all I have is the binary, right? Can I throw that at nDepend?

nDepend approach. It takes what, you give it to him - or to it - and then he does what he can. And for example, if the source are not in synchronization with your DNA, it will emit some warning. So that can be also useful and also something very recouping. Like you are referencing a version, but actually the version you get is different. The reference version and the version assembly are different. Typical situation nowadays with all the NuGet package that are all using each other. Again, this plan can help with this kind of thing. You should be really careful about it.

Also some wide range of feature I didn’t mention yet is all the graphical aspect. It’s all the code visualization things because we talked about the dependency. But it’s interesting to visualize dependency. So there is really three ways to approach the dependency with nDepend. First, there is a dependency graph and I’m very proud of it. I mean, we worked very hard and I think I think is the top notch you can get in the industry by now in terms of dependency visualization.

It can, it can work for example on like the 15,000 classes of the .NET core. It can analyze and you can visualize it with zero slowdown on standard hardware. For example, just to compare with what you can get to some other tool. So even on very large code base it will let you visualize all your dependencies. It will also navigate. There is a lot of navigation things and search and you want to see the coupling between two components or you want to see a code graph. Like from this method I can reach, what can I reach from there? So all the dependency needs you can think of typically they are unlimited. Here what I Like is that we are really dog fooding a lot our model and we are really spending a lot of time in nDepend every day to analyze nDepend and do. Especially now that we are doing all this migration thing, this improvement things that we are doing or reorganizing our dependency. I can see how useful this kind of tool are there.

So you have the graph, you have a dependency matrix that historically was the right way for us to see the dependency because the reason is that dependency matrix is scaling. So for those that don’t know what is a dependency matrix, you know what is the matrix. There are some rows, there are some columns. So you get some component, say some classes namespace or assemblies method, whatever in rows and the same for column. And then you get the sale and interest sale is non empty. It means that there is a dependency. So the dependency can be from row to column, column to row or both or empty. So they are the four. So I allow you to see and at first we used a lot this way to realize con because it scales. Because the problem with the graph is that if you have say 1,000 plots typically on most graphs it will be totally unbeatable what we did with nDepend. And because the graph has been related two years ago during the COVID crisis actually. So it was a very productive lockdown. What happened is that we found a way to scale with the Graph. There are several ideas that you can get graph inside the box of larger graph so you can get nested graphs.

We are also a cornering shame. So we use several visual approach and typically you can visualize any large piece of code and you can go from top down, you can zoom in. So I think that was the innovation we brought two years ago that cannot be found in any other project to really scale with the graph. But now it means that you have very polished dependency metrics and a very polished graph. And the third approach to cope with dependency code query I mentioned earlier, like we can do some rules, but what’s interesting is that you can do anything with code query.

So for example, you can plot a metric, for example, you can plot the percentage coverage of a component. You can just write a little code query that returns color and then you can plot this color across time and then you get some trend which is another feature nDepend. But you can also query the dependency. You can ask for a class, tell me which class depends on me and also the class that depend on those one and also the class, et cetera. So you can construct a call graph. This is interesting because the graph and the matrix are generating the code query. So most of the time you won’t have to write the code query because they are generated for you. So you have the code query results, which is very optimized. Again, it can scale millions of line of code, et cetera because it depends the different approach. And you can work with the result and the graph at the same time, which is very useful when you are doing large scale refactoring or let’s say for example of a large monolithic code base. So it’s very useful to have all these tools working together and visualize things.

And also when you progress with the tool you can write your own code query. And for example which classes in this component is using the WPF because I don’t want any WPF anymore. And then tell me which methods or classes of the WPF are used and how the amount of usage, the amount of coupling, et cetera. You can write your own query to do that and then you can redefine I have a query, I have a result and my task will be done when the result will be zero.

Right.

This is quite a powerful approach. Powerful and also different approach to understand code and have better quality code. But it’s again, it’s no better or less interesting than the typical tool it’s getting was in. It’s just a compliment approach.

I think I like it. Yeah, because when people say to me hey - somebody will say to me, “hey, this, this tool exists, this software exists, why make another one?” And I’ll say to them, “well, you know, we wouldn’t have Windows and Mac OS and Linux is if somebody just went you know what, XEROX Spark exists, we just won’t bother making another one.” Right? Because the problem that Roslyn solves is subtly different enough that the problem that nDepend solves. There’s a world of difference. It starts with this subtle difference of well, “Roslyn is going to focus on the tiniest of details and oh, you spelt that wrong or you’ve put a curly brace on the wrong line,” and then nDepend upend goes in the other direction. It’s like, “we want to know about the dependencies, we want to know about code quality, we want to know about psycho metric, dependencies, psychometric, all that kind of stuff,” right? Exactly.

They are very good tool to in Visual Studio. They are also dotcover, they used to be encover, they are nCrush also, which is awesome. They are very good tool to produce some code coverage data. But then you get the data and you get few tools to do something with the data. And this is typically where nDepend come into play. It will read all your data, coverage data, whatever tool you are doing and then you can start doing interesting things. There are like ten rules per default on the coverage data. There is something also that is very interesting to me that you can put some attributes and for example, we have the FullCoverage attributes which mean that by design this class should be 100% covered. And then you can write a rule that says tell me which one target is full covered but not 100% covered. For example and this is very interesting because actually I didn’t talk about test much, which is another very important aspect when you’d want to do the right things.

And at the very origin the technical test metaphor was all code not covered by test not tested. Because covered is not enough, it must be tested as well. Okay? It’s not about enough to be just at the very beginning, but then you can also put things like API breaking, change and all this kind of problem I mentioned earlier to put in your debt to extend it. But what’s interesting is that when I analyze the code base, the .NET code base fully covered, I can see that 70% of the debt is is from there, from from the few rules about poor code coverage. And when I look at my technical debt estimation, I can see nDepend smart enough to really see there you have your biggest problem is that your code is not covered.

Something I would like to mention: so I said about coverage and also about testing. So this is different thing. Coverage, it means that the line exercise and the line is tested when you make sure that the results obtained from the line is the results you want. Okay? That’s two different things. There is something I never saw anywhere in the industry but in our shop. It’s natural. So I would like to say that typically you get the assertion only in your test code, okay? Asset display is not new, et cetera. But few developers are using assertion in the code itself. And I think it’s a drag because in the code itself. This is really where you get the results. Of course, the results. It’s not like in the test where you get some input and you expect some input, but so many can be done with assertion in the code itself. So we wrote our own small framework where we get both our assertion in code and in test. It means that we have so many more assertion exercise when we are running all our tests. For 14,000 tests we have so many more assertion, millions. Literally, we are using nUnit, it’s I think 13 million or something like that, assertion exercise. And sometimes we can see the assertion in code are violated and sometimes it’s in test. But it’s not just in test. It’s really another way to make sure you could to find the bug early to avoid regression. This is not related to nDepend because independence is not an assertion framework or whatever. But this is something I don’t see enough in the industry.

And also, for example, another topic which is important, which is UI testing. It’s very hard to test the UI. Like I click this button and I get this text in the text box. It’s very hard to do. You have to have some framework, but it’s a lot of work and it’s toddy fragile. Suddenly the button becomes a regular button and then you’re stuck. But if you can pilot your UI and then exercise all the assertion inside your UI code, then you have a way to both cover your UI code and also exercise enough. Maybe not everything as you would get in click this button, et cetera.

But still we have a few tests like that. They are very long, they are like 37 tests. Because for example, for the graph we test, I have a small YouTube video. I can communicate you so you can share with listener. You can see all the graphs working alone, we don’t say anything and then we verify. So much fun in the UI without maybe not make sure that this pixel is gray and this one is white, or this text box. This is a different approach. But this works because when we introduce bug in our UI, which happens often because this is how the software works, it’s hard, but then it’s automatically detected this way and it means not much extra work for us to test our UI and to be confident that we didn’t introduce breaking change in it. This is just things I wanted to discuss because we are doing these things a bit differently and this works. And this saves us a lot of time and a lot of problem with some Is users.

Yeah, I really like what we’ve said so far today because I feel like I said, when you go to someone and say, “this part of the code needs work,” or like if somebody said to me, “go fix some technical debt well,” I’m not just going to roll around in the code base looking for it. I need the data that says to me, “this bit, this bit here, go look at this bit.” Because this bit is where if it’s going to fail, it’s going to fail here. I like that, I like that nDepend and similar tools can get me that.

So I guess as we start to wrap up here, Patrick, because we’ve been talking for going on an hour, and I’m aware you said before we started recording, you had a bit of a cough going on. Let’s not carry on too far. I don’t want you to wake up tomorrow and not be able to talk because of me.

But that’s true that as a developer, most of our day we are not talking that much when you are inside your IDE. So it’s always interesting to have a good talk with a fellow.

What’s the best way that folks can maybe learn a little bit more about you and definitely to learn a little bit more about nDepend outside of the show? Just before you say a bunch of things, if you have any links, I’ll make sure that they’re in the show notes. So if you’re listening along, don’t worry about writing them down and going, “oh goodness, this is awesome, I want to learn more.” It’s all in the show notes, right? So you can press though and find those things.

Sure. So just quickly, nDepend come[s] with a three SKU. So first you have the developer edition. So this is where you get all the graphical things. So it can run standalone on Windows or inside also Visual Studio any version from 2022 to 2010. And of course next version will be ended. We also have plans to support Rider, which is increasingly getting some share in the net CD. So this is the developer approach. When you want to have an interesting thing, you can also analyze your code in Visual Studio. You can get a snapshot, run analysis very quickly, any time, pass all your roots in a matter of seconds. So this is interesting, as I said, to get all the new issue, you were introduced against the baseline snapshot. You are comparing it. So this is the developer edition.

Then you get the Build Machine edition. So the Build Machine edition, you put it in your CICD, then you can get reports. So the report, it can get some graph, it can get some technical debt estimation. It also contains all the issue things, all the issue rules are passed, et cetera. So this one works on macOS, Windows and Linux. Okay? So this was the first migration phase that happened actually last year. So we have all our non UI code already in .NET Standard and this is how we can run it on Windows upon .NET Framework, but also on Linux above the .NET Core. Okay?

And the third SKU is Azure DevOps So we have a full fledged hub. It’s not just a report, it’s much more interactive than a report. So if you are using Azure DevOps, you can also try this edition and see if it fits your needs.

So it’s really the way you want to use it. Do you want to use it in your IDE, in your Azure DevOps, in your CICD?

We are now working on GitHub action. Okay? So we’ll also have a GitHub action edition to be in GitHub. I’m not sure when this show will be released. So maybe at the time you listen to show, maybe the GitHub action is already there. So just have a check. So of course just go to nDepend.com. You can try all the SKU from the download page. Okay. For the Azure. DevOps, you need to go to the marketplace. Azure DevOps. There is also a free trial, full feature but time limited.

I think it’s interesting to just download it, scan your code and see what the tool can say. Work for a few days, scan again your code and compare it against the baseline and see the difference you will have. And especially in terms of issue and technical debt because as nDepend can say about the new issue and the fixed issue. Of course you can also compute the new amount of technical debt introduced or fixed. So you can measure if you go in the right direction or the wrong direction and you can plot trend, et cetera, as I said earlier.

So yeah, just try it. Promise. It’s very easy to install, it’s just XCOPY. I like XCOPY. I don’t see why since our users are developers, I don’t see why they would need to do something else that just zip and let go. So it’s very easy. As I said, the dependency are something very important for us. So the registered view table is very lightweight, like 13 megabytes. I know some flashlight, application weights, more than that so you get all this feature.

Also, this is really related to the minimalist approach I talked earlier. Like also do more with less software alike. It’s really important to control your dependency. It’s really important to control your amount of code.

Okay? When I see some redistributable like one gigabytes, I can’t understand that maybe for Visual Studio, but for some other projects I have had time to why the hell 1GB of my computer should be dedicated to this application that don’t do that much. I like for example the 4K demo. Some guys are doing extremely nice demo, only 4 KB. So I like this approach of being minimalist. And this is also related to all the performance things because typically if you are carving with your code to be small, there are high chance that you are carrying for your run time the amount of memory your application is consuming. Certainly it will be small as well because somehow it’s related. I like to care about the size and software because unfortunately we don’t get extra CPU cycle, we get extra cores nowadays, like I have 16 cores but I don’t have more than like four or 5 GHz. We won’t get more than 5 GHz. So I like the idea to be minimalist and do the best to code, like if you were in the don’t do that much if it’s not absolutely necessary.

This is close to what we were talking before.

Of course I like that. I tried to take that approach myself. I’m sure long term listeners have heard this way too much when I say this, I take the Charles Emerson Winchester III approach. I’m not old enough to have seen it when it first came out, but there was a sitcom in the 70s called MASH and there’s a character in there says, “Gentlemen, I do one thing at a time, I do it very well and then I move on.” And the only way that you can do that is by doing things like in the smallest possible fewest number of steps, right? And that’s all the program is. You’re telling the computer to take these steps to solve this problem. And by having the smallest amount of possible steps you can go through, your dependencies there, your tracking there just drops through the floor. The difficulty in supporting that code, just the difficulty drops so much just by doing exactly what it is you want to do.

So I agree with you completely about let’s control our dependencies. Let’s make the simplest code possible because at the end of the day, whatever code I write, I have to support and me tomorrow is a different person to me today, right? So technically it’s another completely different person who has to support the code. So let’s do that.

This is also the idea of the definition of done, which is nowadays. So for us, when the code is still freezer session, it’s 100% covered, it passes all the performance testing, we done it’s okay. It’s important to have your own definition of done. And when all these steps I mentioned are respected, it will be very hard to break the code necessarily. You will break the compiler or you will break the test. But if you follow everything I said earlier, the code will be very maintainable. And now I can measure how precious because of course we are applying all our advice, we are applying it with ourselves. Before .NET core, we couldn’t imagine the net will undergo a total revolution, right? We were at home, we were on Windows, WPF, it works nice. We couldn’t imagine that at the point we’ll be, I don’t know, [].NET] Maui on Mac or whatever so we didn’t realize that it was interesting to do a very maintainable application. But suddenly we really need to benefit from all the effort we make earlier because suddenly there are tremendous refactoring we need to achieve. And really we measure every day all the effort we make in adding a very layered architecture. Testing total 87% testing covered by test, and nowadays it’s really a breeze to refactor. I don’t know, in terms of line of code, I mean, in terms of second breakpoint, I mean, the things you put in breakpoint, it’s like 100,500 a day. We can refactor with a lot of confidence.

It goes very quickly, which means it’s good for our future. But yeah, it just works. If you follow all these advices, it really works.

It does. So what I’ll say, Patrick, is what I’ll say is thank you so much for being on the show so far. I really enjoyed our conversation and there’s lots for people to learn here. What I’ll do is I’ll collect a bunch of links from you outside of our recording and make sure that they go into the show notes, and I’ll try and as best I can, folks, go check out nDepend, right? That’s me telling you, go check it out.

Thanks very much for invitation, but it was a pleasure to talk.

Yeah, you’re very welcome. It was a real pleasure. Excellent. Thank you for so much. But yeah, it’s been a real pleasure talking to you, Patrick. Thank you.

Thank you.