For one and half years, we have started experimenting NDepend in our daily work at siemens healthcare and now we can see the benefits of using it in terms of:

• avoiding breaking the build,
• Impact estimation,
• Software quality.

The choice of NDepend came after one team developing a basic layer in the system did some behaviors and API changes without controlling correctly the impact. "No one is using this" or "just one line changed" ... The result was a real tsunami the system was not usable and not deliverable during 3-4 weeks!

How did we avoid that such scenarios will come again?

The idea is quite simple before submitting his public changes the developer shall

• Check for the impact, answering the simple question: who is using me?
• Inform the affected component responsible
• Agree with them in which build the change will be submitted
• Collect the modifications and run the affected smoke tests
• Submit the overall changes into the main build

You can say it is too much. For sure for a team of 3-4 people it is overkill but for more than 100 developers dispatched all over the world it can help them to always deliver a running system.

To allow the developer to check the dependencies, we generate the NDepend repository in our main build. I can remember with the first version (2.6) we used to use a 3.2GHz 64bit 8GB RAM machine and the overall generation took about 25 min from a Clear Case virtual file system (a classical file system it was about 10-12 min). The performances increase continuously and with the latest NDepend version 2.11.2, I can generate all the project on my 2GHz 32bit 3.2GB RAM laptop in less than 6 min always from a clear case virtual file system. This increase of performance opens new perspectives for the developer, he can always work with the latest repository, because he just has to generate it locally. And let imagine while coding that NDepend informs you in real time about the impact 88|

Back to the reality of finding the code impacted by a change. It is a kid's stuff with CQL. With the following queries you will be able to avoid breaking compilation in your main build:

SELECT TYPES WHERE IsDirectlyUsing "YourType"


SELECT TYPES WHERE DeriveFrom "YourType"


SELECT TYPES WHERE Implement "YourInterface"


CQL also allows you to query on Assemblies, Methods and Properties level but from my experience the TYPE level is a good compromise. Assemblies are a little bit too macroscopic and Methods/Properties is too microscopic (sometimes). Now we are able to find all code affected by a change to avoid compilation errors. But is it enough? I guess not, we have to provide a running system! Compilation is unfortunately not enough to declare a system running... It is also important to run some tests ;D.
When you work on big code base you are always facing to the test execution timing issue. It is not always possible to run all test cases after each change. We have to find a way to execute only the most relevant test cases corresponding to the change.
I propose to execute the following query:

SELECT ASSEMBLIES WHERE IsUsing "YourType" AND !IsDirectlyUsing "YourType"

You will find only the indirect dependency. That means those assemblies will not be affected at compilation time but potentially at runtime with a behavior change. Running the smoke tests of the found assemblies/components, you will be more confident of delivering a running system.

Impact Estimation & Quality

NDepend also helps us to estimate our back log items during the iteration planning. When you plan or you have experiment some refactoring it can help you to see the real impact on the whole product using the build comparison feature it is really easy (more info).

We are also using the different metrics provided by NDepend in our in-house metric framework to qualify each sub-system.

This is just a sub-set of the capabilities offered by NDepend and CQL! They can really more. Thereby to the NDepend Team keep up the good work!

PS: I am a little bit late for the Santa claus order but perhaps with the time difference between Erlangen and Nice it can be possible to obtain :)):

• Plug-in mechanism for Runtime dependency check (private, spring.Net, …)
• Multi language support (Java seems to be on track with www.xdepend.com)
• CQL complex Query support (multi select in one query)
• In the visualNDepend class browser the possibility to apply some filter, (a CQL filter perhaps). If you have a lot of assemblies you can easily find the targeted one without scrolling through the whole list.
• Plug-in mechanism for the NDepend project. You are currently supporting VisualStudio but what’s about MonoDevelop, SharpDevelop eclipse or others…