NDepends 2.0 and Managing Change

Scott Hanselman has posted a really interesting article on NDepends 2.0.

I think the main thing that actually interests me about this tool is the ability to find the really bad edge cases. I'm of school of thought that says our primary job as developers is to deliver business value. One of the things I've been guilty of within the last year is the mistaken belief that it is better to throw out working code then to properly refactor it (in my defense I had not yet read the Refactoring book.. or anything by Martin Fowler at this point). I now realize that instead it makes more sense to refactor things in pieces.

Of course this understanding is just the first step. At some point we have to decide what to actually refactor. There are a few ways to drive our refactoring. The most obvious is new functionality. Whenever you enter an area you should leave it better then when you arrived. Even if all you do is take a minute to clean up a method at least you've accomplished something. Next in line comes bug fixes. If you're fixing a bug you should be improving the area (after you added a Unit Test that shows the bug).

But you may (or so it's been rumored) get to a point where you have a few spare moments and no new functionality to add or bugs to fix. It's at this moment that I think NDepends will really have value for me. Because now I can start using its functionality to find the code that is much too complex or components that are in the "Zone of Pain". And I can take some time to improve things piece by piece.

I also gain the ability to get a higher level view of the interdependencies that may not be obvious at first. With this knowledge I can decide whether I want to start small with something that isn't going to cause a potential cascading effect, or at least be forwarned about what I'm getting myself into if I decide to go after something heavier. Knowledge is power after all.