Stories about Software


Why NDepend Uses Google’s Page Rank

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, have a look at type rank and all of the other metrics that NDepend will show you about your code.




The Decline of Page Rank






A Useful Reappropriation of Page Rank




Code in Terms of Risk

All right, so that’s an interesting exercise.  In performing it, you might give elements of your codebase popularity scores, if you will.  But what substance do you get?

Think in terms of risk.  High rank — popular — types receive a lot of trust from the rest of the codebase, just like a study published on a government or university website.  Other types depend on them, both directly and indirectly.  So when you make changes to them, you incur significant risk.  At best, you might create compiling and building issues.  At worst, you might introduce subtle bugs with broad-reaching impact.  On the flip side, when you change low rank types, you incur relatively little risk.  Nobody depends on them, so if your immediate changes check out, you can have confidence in the code.

In a sense, then, meaning of high rank inverts for codebases as compared to your website.  For the internet, high rank implies high credibility, stability, and popularity.  In your codebase, it implies popularity as well, but popularity means dependency and risk.

Taking Action for Type (and Method) Rank

So does this mean high rank is bad?  Well, no, not necessarily.  It could indicate an architecture that consolidates too much, but you will naturally have more inbound dependencies for some types than for others.  You can’t avoid that.

But high rank does unambiguously mean risk.  So the first thing you need to do is make yourself aware of it.  NDepend will show you your highest ranked types.  Avail yourself of this knowledge and keep an eye on them, particularly if some of them really start to accelerate upward as the project progresses.  (The same logic also applies to ranking dependencies among methods.)

Once you have a sense of these types in your codebase, you can form a plan of attack.  Watch for changes to these types, and when they happen, ensure you have plenty of testing in place to mitigate risk.  If you observe frequent changes to these types, understand that you have a high risk architecture.  Try to work toward a state where you seldom change your highest ranked types.  Conforming to the open/closed principle can help here.

To generalize, make sure you understand the risk and have a mitigation strategy in place.  I stumbled through blogging for a number of years before figuring out the importance of rank and how I can use it.  But I had really low stakes compared to someone responsible for a production codebase.  Make sure you understand how you can use the page rank algorithm to your benefit in your codebase.