Keeping Quality

I got a comment some days ago that the design and quality decreases over the lifetime of the product and that it's not possible to keep the initial quality. I strongly disagree*. This is where TDD and NDepend comes to a rescue. TDD is not (only) about test but also design. What is the first thing you write in your test method? Is it an Assert statement or is it how you interact with your service under test? If you skip TDD when the product becomes bigger then your quality will decrease.

But how do you set design rules for your system e.g. that you should follow DIP? That's where NDepend comes to rescue. Set up a rule that says "do not depend on a specific external system". If you have your infrastructure, external dependencies, etc in their own assemblies (App.Repository for example) then you can write the rule something like this:

  WARN IF Count > 0 IN
SELECT NAMESPACES FROM ASSEMBLIES "App.Model"
WHERE IsDirectlyUsing "App.Repository.*"

If someone adds a reference to this assembly from your model, tomorrow, next summer or whenever, then the alarm will start to sound!

If you do some clever rules and use TDD then I think you can have design and code quality in the future as well. But, and it's a big but, you can't and you shouldn't put all the trust to the tools. You need co-workers that understand why you should follow the dependency inversion principle, how to write good test, and so on. That's the greatest chance to keeping good quality in your system!

* I disagree that it's not possible, not that it's a fact for most systems.