Dependency Structure Matrix Add-In For Visual Studio

Based on the work of Neeraj Sangal, Ev Jordan, Vineet Sinha and Daniel Jackson in the paper: Using Dependency Models to Manage Complex Software Architecture you can now, direct from your Visual Studio solution :
  • Visualise software architecture even for large projects
  • Untangle complex inter-module dependencies
  • Identify design violations
Available for:
Download here - run the .MSI to install, then see README (in install directory) for further info.

To report bugs, suggest improvements or for any other feedback please drop me a mail

22 October, 2014

What is Your Branching Model?

…asks Paul Hammant
We have a team of 6 developers and 1 release/QA Engineer; we practice Scrum and have  4 week  long sprints and we’re a subversion shop. We hold a demo at the end of the 3rd week and as we don’t have dedicated testers everybody is involved with testing during the final week. Every Monday is our regular bug-fixing day. 

We have a standard product and we do trunk-based development for that; new stuff and bug fixes committed to trunk. We have a nice system of Feature Toggles (more another day) and so far have had little need for Branch by Abstraction.

When testing is complete and bugs that need fixing are fixed, we redeploy Head to the server and our release engineer runs some final tests (typically he runs some manual sanity tests and validates the corrected bugs). If all is good the version is tagged.

For this final test we don’t bother creating a release branch, we’re small enough team to say no commits allowed until further notice, although the release engineer may commit one or two minor corrections. This usually takes half a day.

Alongside the standard product we have many client-specific versions. These are maintained by a separate ‘services’ team (2 or 3 developers). Their release schedule is much less onerous than ours – clients don’t like change. Each non-standard client has their own branch and when they want to update to the latest standard, they merge from our tag.

We’ve had this system in place for at least 18 months now. Up until then we had two (large) releases per year. For each release we would make a new (permanent) release branch. To this day we have a few branches of this type but they are being phased out as clients are upgraded and now it’s very rare that we bug fix on these. For clients that are still on these versions, we bug-fix on the corresponding standard branch. Our release engineer manually merges these fixes up to the next version whenever necessary. The service team tends to cherry pick fixes from these branches merging them to their client branch.

The move from 2 to 12 releases per year has significantly improved the quality of our releases and the near absence of the need to maintain old versions has made things much simpler.  We’re still not satisfied with the quality of our software although it’s evident that there is no comparison when there were at most two large releases per year.  I put this mainly down to the absence of having ‘real testers’ in the team.  So far we’ve found it difficult to convince management to recruit people with this profile.

22 April, 2014

Version 2.1 Dependency Structure Matrix add-in for Visual Studio

New features

  • VS2013 now supported
  • Solution Folder level projects are now included in the dependency analysis
  • Auto-update mechanism
From this version on, the add-in will connect to this site on start up to check for new updates. For users of previous versions it will be necessary to manually download and install version 2.1. You may be required to uninstall any previous version first.

Ideas for future versions

  • Allow the creation of dependency rules and report contraventions as part of a CI pipeline
  • A standalone version – so that non VS/Reflector users can generate DSMs
As always I’m very interested to hear your suggestions for improvements and new features – let me know!

25 April, 2013

Quality From Up-High

Over at InfoQ Erik Doernenberg gives a nice talk on Software Quality presenting some simple and not so simple metrics along with some thresholds for giving a general quality overview of your software:
  • Cyclometric Complexity per Line of Code
  • No. of methods per class
  • Lines of Code per method
  • Lines of Test code to lines of production code

Based on these metrics it's easy to knock up a simple dashboard in Excel. At the end of each sprint I run the Calculate Code Metrics tool in Visual Studio and import the data in to my database. The Excel spreadsheet retrieves the data with a couple of SQL requests.

Some graphs plot the data over time:

24 April, 2013

The DSM Plugin featured on

An in-depth look at how my DSM plugin can help you analyse your architecture at
[Original post from 2009 : migrated over from]