Dependency Structure Matrix Add-In For Visual Studio Download or Find out more ...
Visualise your software architecture, untangle complex dependencies, identify design violations right from inside Visual Studio.

05 May, 2015

A Feature Flipping Implementation

When we started thinking about moving from 2 to 12 releases per year it was clear that we had to manage the fact that some new features would have to be in a deactivated state until the ‘epic’ user story was ready to go.  Often small bits of functionality don’t make sense on their own at least from the marketing and sales point of view.  After reading about feature toggles it was clear that this was what we needed.  But the question we posed ourselves was how do we go about implementing that ?

Our product is used by organisations of all sizes to help organise their training needs, create training courses, register staff in online and presence-based courses, provide tutoring and reporting tools etc. etc.  In most cases our clients (especially large organisations) have their own particular structures and particular workflows and most notably their own differing rules on who can do what and to whom.

So from day one we have had the requirement to provide a product that is very finely configurable.  Access to each and every functionality is controlled by a particular privilege.  For example are you allowed to view a certain user’s profile ? There’s a privilege for that.  Can you edit a certain user’s profile? There’s another privilege for that.

Around the same time Sales had been pestering us to give them the possibility of deactivating certain features.  Customer X does not want functionality Y and hence expects to pay less.  Can we make functionality Y invisible to client X?

Quite quickly we realised that our toggles were already in place in the form of these privileges and by grouping them according to some given licence key we could control blocks of features by providing a new licence file. 

Our privileges are heavily used behind the scenes in plumbing code such as by the sitemap provider which validates access to every page.  Otherwise, the visibility of buttons and other page elements are controlled by a function call to the role provider service passing in the privilege name as a parameter.  The important thing here is that we don’t have any specific code that you might want to remove later once a feature is deemed ready.  We only have privilege checks which are functionally always necessary.
btnEditUserProfile.Visible = Page.IsUserInRole(“Edit.User.Profile”);

All our privileges (and other stuff such as application parameters) are declared as application metadata which have a property “LicenceKey”.  This links the metadata to a known internally published licence key which in turn can be added to the client’s licence file if required.  For features in development that are not ready for deploying we use a private licence key such as “dev” or something more specific when there’s the possibility of activating a block of functionality for a client demo for example.

We were lucky that we already had the privilege functionality in place and it was mostly a matter of refactoring the metadata and a small number of services to take account of the licence key.  It’s so far been a great success and very easy to develop fully ‘toggable’ features with very little effort.

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]