Creating a Culture of Quality

I’ve been testing my code for a long time.  I finally got on the TDD / BDD bandwagon a year ago and haven’t looked back.  But as much as I believe that testing is important, and I would never write professional code without an extensive suite of unit tests, I still find myself writing code at home without tests.  The reality is that it takes discipline to keep a test driven approach to software development on track.  When talking about a company that follows these practices and has the normal turnover of staff, it become even more important to have a culture that embraces, encourages and, when necessary, enforce quality at all stages of development.

So how do you create this culture of quality?  It doesn’t happen overnight and it will definitely doesn’t happen on it’s own.  You’re entire team has to work toward creating the culture that embraces it at every step.

Make it Easy

It takes a great deal of work to incorporate quality from the beginning of the project.  Don’t make it any harder than it needs to be.  An automated build process is extremely important.  You need to be able to be able to “push a button” and compile and run all unit test for your entire application.  There are a lot productivity tools help with this too.  In the .Net world, Resharper should be a required tool in your toolbox.  The refactoring and navigation enhancement it provides make it possible to take a continuous design approach to your application.  Integrated source control and testing tools are also important.  It needs to be simple and easy to run a single or all unit tests, and if you can do that from within your IDE you are off to the races.

Code Coverage

Having a high level code coverage percentage is one way to ensure that you have quality in your process.  High coverage by itself is not an accurate measure of quality and 100% coverage is not going to guarantee it.  However it is low hanging fruit, and it can give you a level of comfort when it’s time to refactor to a better design that you will not break existing functionality.

Continuous Integration

Continuous integration is the best tool you can use to help create culture that expects quality.  In a CI process, you can set the build to fail if any of your test fails, or if you fall below your test coverage threshold.  This gives the team immediate feedback when something goes wrong and can be fixed immediately. 

Don’t Leave a Build Broken!!!

Even if you have a CI process in place that runs all your tests and measures your code coverage, if you allow the build to stay broken, all of your work is for nothing.  At the same time, breaking a build should not be a criminal offense. You want your team  members to commit their changes frequently.  When they do this it’s okay to have a build fail.  You don’t want developer to be overly cautious when committing, fearing a broken build.  What you don’t want is to let a build stay broken.  If you leave a build broken for a long period of time, it is a symptom of apathy about keeping the code base at a  high level of quality. 

You should also never commit changes to a broken build.  You don’t know what impact your changes will have on a systems that is not passing all of it’s tests.  Also remember that the team has ownership of the code.  Anyone can fix the build (that includes you), it doesn’t have the person who broke the test.

There are lots of ways to enforce this.  The easiest way is that tools like CruiseControl and TeamCity (I think) let you attache sounds to build events.  One thing Jeffrey Palermo does is to have everyone on the team choose a sound for build success and failure.  This gives the team positive and negative feedback to the build process.

Many people hook up a red strobe light to the build system.  That way it is glaringly obvious to the team that something is wrong.  A variation of this using a lava lamp and the goal is to fix the build before it starts bubbling. 

The danger here is that you don’t want your team to fear committing frequently.  Life becomes much harder if people leave lots of code modified while they are working on a story or task.  As I said, it’s okay to break the build, just don’t leave it broke.

Bugs Are Blocking Issues

When working on a new project and you’re got all of these story cards for new features, it is not much fun to work on bugs.  But it is essential that when bugs are found during the development phase that they are placed on the board as blocking issues.  If there are any reported bugs on your task board, you finish those before starting a new story.

These are just a few techniques you can do to instill a culture of quality in your organization.  I’m sure there are more.  What do you do to create a culture that values quality?