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?

This entry was posted in TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Uncle Bob

    ” If there are any reported bugs on your task board, you finish those before starting a new story.”

    Really? Even if those bugs are minor and are less important than other features that customers are asking for? I understand the point that you are driving at, but I see many developers put building perfect software as their primary goal and put the needs of the business or the customer as a secondary goal. I’ve been in meetings where there has been a bug that has affected 1-2% of our customers in a minor way and developers get quite upset about not having the time to refactor and rebuild that portion of the code because it was decided that implementing a new feature that was requested by 70-80% of customers and represented additional revenue for the company, not to mention a competitive advantage.

    So while I agree with you and I’m probably splitting hairs, there is a time when it’s ok to leave bugs and focus on other stories.

  • John please be very careful with this mindset because it can lead to putting tools over people. I did it myself for a while.

    The agile manifesto states, “Individuals and interactions over processes and tools”.

    To ensure the greatest quality, talk to your people, pair program with them. Ensure that they don’t have fear by letting them know you won’t judge their code or yell at them if they break the build. Don’t let a sound or flashing device speak first.

    If your suggestions are after you have successfully conquered the people aspects of quality, then I completely agree they are valuable next steps.

    In agreement with you about the CI tool and it’s communication back to the team:
    We use the mortal kombat sounds in our lab.
    Successful build = “Flawless Victory”
    Fixed build = “Excellent”
    Broken build = “Fatality”
    Continuous Broker Build = “Get Over Here”

    When we here the broken build noises, at lest 2-5 developers are bringing up the CC.NET web dashboard to see what happened. We’re trained that we have to tackle it immediately.

  • jcteague

    @Uncle Bob
    Your Point is well taken and there is always a trade-off. Then answer is of course it depends. I’ve been in situations where a bug was reported early in the project and it just sat on the board while other, more interesting tasks were worked on.

    Now if you’re near the end of the project and you’ve got to get XYZ done before you go live, that is a judgement call. But I fear if you continue to let bugs show up on the board without addressing them you are accepting a level of mediocrity that will eventually lead to a mediocre product.


  • jcteague

    Excellent point and should probably be the first item on my list. Pairing is the best way to not only ensure quality, but to keep the level of profeciency on the team high. I think that deserves a blog post to itself.

    With the exception of R#, I try not to depend on tools too much either. My point was that there are some low friction, easy to use tools that will make it easier to keep a high level of quality in your code. But this is making an assumption you are taking care of the “people” aspect first.


  • This is awesome! I have something like this in my queue of topics. Make it easy applies all the way across for me. In every aspect of development, make it super easy. Make it easy for the guy that just got called in at 10PM to fix your code. He shouldn’t have to give you a call if it’s easy enough. I just wrote a post about developing with quality in mind, but from more of a maintenance standpoint. I think it follows the same lines, but from a little different perspective.