Introducing Quality-first Notions Into an Existing Team

In a recent discussion on the altdotnet mailing list, a question was raised: How to you start introducing TDD into an existing team?  Bill Barry had some good thoughts on how the process might work, I suggest you check out his post.

It got me thinking about things and three questions came to mind:

  1. If the team is functioning and delivering software, why introduce anything at all — especially such a radical change as TDD?
  2. When implementing TDD, what’s the best way to get it going (i.e. mandatory/imposed, weaving in little by little, separate project, etc)?
  3. Won’t this just add a bunch of time to my process?

First Question: Why introduce TDD into an existing, functioning team?

What if the team is already having success with their current process? Why add something so different as TDD and risk potentially screwing everything up?  Bill touched on this in his post, but I’d like to expound upon his point. His point was essentially: Is it really working, or does it just appear to work? Shipping software is not the only metric. Is what they’re shipping as high quality as it could be? Could they ship faster? Are they working as efficiently on the code as they could be, or is a large percentage of their time spent on up-front design, bug reproduction and resolution, and other otherwise-avoidable activities?  The first thought that came to mind is: Sure, you may have a bunch of heroes on your team that, through blood and sweat manage to pull off successful releases, but at what cost?

I get this a lot when talking to people about TDD. I hear things like, “But our process is working great, we’re shipping software on time and customers are happy!”  That’s wonderful and I applaud your success. So now that you’re making customers happy, could you be making them happier? Could you be saving your company money by making your successes even more efficient? Let’s take it to the next level! Let’s make customers ECSTATIC! One vision that comes to my mind when people say they are having ‘success’ is a circus performer juggling balls in the air while riding a unicycle.  Sure, that performer is an amazing expert in his field and extremely talented. However, if his task is to deliver the balls to a customer, he’s spending way too much effort when he could just walk them over to their destination.  Are the talented experts on your team juggling on unicycles, or are they taking the easiest, shortest path?  Which delivery method will make the customer more successful?  Juggling my impress them, but it’s not really helping them.

On the other hand, I have seen teams (yes, including teams I’ve been on and even lead — I’m as guilty of this as anyone!) declaring success, but when probed for more details, it turns out that the customers don’t necessarily share the same enthusiasm for the success as the development team does. Many times, in this situation, if you ask customers how they really feel, they may say that quality is ‘acceptable’ or ‘good enough’ or ‘I can work around the problems’.  I will ask the development team what metrics they’re using for measuring success (and the sustainability of that success), quality, efficiency, etc.  Very frequently there is no answer, or everyone stares at their shoes. We can ALWAYS do better. We can ALWAYS improve and eek out more efficiency, more automation, more clarity, and, most importantly, more success for our customers. We should be relentlessly seeking out these opportunities and taking whatever reasonable risks we can to make sure that we’re not missing things.

In my mind, TDD is more than just a coding practice, it institutes this culture of relentless self-examination and improvement — a culture of quality, measurement, sustainability, and repeatability (all summed into the word I use a lot: ‘maintainability’).  TDD is the tip of the iceberg, but it is supported by other good practices such as Source Control, Continuous Integration, Automation, and Code Refactoring — among many others.

Second Question: What’s the best way to go about introducing it?

So, how does one go about bringing this culture to their organization.  Given that I propose that TDD is the tip of a cultural iceberg within your organization, the key is to change the culture and the focus of your team back to quality and customer satisfaction and away from merely shipping the software. OK, OK, I know some of you are going to slam me and say that ‘here those TDD guys go again…’  Yes, shipping is important. Shipping is critical, Shipping is one of the most important features of your project. There, I said it. But I’m also concerned that what’s being shipped is going to make the customer’s happy. And I’d even lean towards the side of ensuring customer satisfaction over hitting imaginary deadlines.  Real deadlines (i.e. the money’s going to run out, we have a legal requirement to implement X by such-and-such date, etc) are a different story, but the values are still very similar.

Anyhow, on to the meat. Here’s one possible recipe for implementing a culture of quality and customer satisfaction in your development team:

  1. Get source control setup if you don’t have it already. Note: this can be the hardest step sometimes.
  2. Encourage frequent source control commits and the taking of source control seriously — not just infrequent code backups
  3. Get NAnt, MSBuild, Rake or FinalBuilder and automate the build. I’ve never met anyone who resisted this.
  4. Set up CruiseControl.NET/TeamCity and get CI going with your new automated build.
  5. Slowly encourage developers to install the CCTray or TeamCity agent tray thingee and encourage them to take build failures seriously. Eventually they will get the build-failure-fever and work to prevent it from happening.
  6. Add in a few unit tests to the build, preferably things that won’t break easily to give positive feelings about there being some tests in the build that pass consistently.
  7. Encourage people to add tests whenever they find a bug to ensure that the bug won’t happen again. This is usually an easy sell as doing the test as a repro case helps fix the bug faster.
  8. Eventually add a few tests that are brittle to get people used to caring when the build breaks due to tests. Then use that opportunity to discuss the best way to write tests in your environment.
  9. Pick a few of the developers who are most interested and/or who have the best attitude and introduce them to the TDD concept and do a short ping-pong pairing session with them on a simple feature to win a quick success.
  10. Keep doing more of #9 until someone else gets it and wants to help.
  11. Start doing more and more until it catches on throughout the whole (or most of the) team.

Third Question: Won’t this just add a bunch of time to my process?

This one is easy. In my experience, these practices pay for themselves rather quickly. The ROI on ‘sharpening your saw’ is usually very quick.  An ounce of prevention is worth a pound of cure, after all.  There is a startup cost, to be sure, but as long as you focus on the values and principles and ditch what doesn’t work and try what you think might work and constantly re-evaluate your practices, you will quickly shake out a set of practices that are right for your team and amount to force multipliers.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Chad Myers

Chad Myers is the Director of Development for Dovetail Software, in Austin, TX, where he leads a premiere software team building complex enterprise software products. Chad is a .NET software developer specializing in enterprise software designs and architectures. He has over 12 years of software development experience and a proven track record of Agile, test-driven project leadership using both Microsoft and open source tools. He is a community leader who speaks at the Austin .NET User's Group, the ADNUG Code Camp, and participates in various development communities and open source projects.
This entry was posted in TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Tucker

    The application I support is massive and most of the logic is in the code-behind of the user controls / pages. I’d love to be able to start writing some meaningful tests for this but don’t know where to start without re-writing the application to move logic to a business / service layer.

  • http://www.mattblodgett.com Matt Blodgett

    Great post. Yeah TDD is great, but how do I convince others in my company (especially managers) of its greatness? That is the question. You’re interested in answering that question, which I appreciate very much.

  • http://chadmyers.lostechies.com Chad Myers

    @Tucker: Don’t rewrite. Pick out small victories, like some new features that you can introduce new micro-designs that don’t impact the system too much. Maybe there’s a side-project or an opportunity for a utility/tool that you can use the new stuff on.

    Working with legacy code is tricky, and there are several strategies for it. Michael Feathers has a great book about working with legacy code (search on his name).

    Also, LosTechies bloggers Jimmy Bogard and Ray Houston did a short screencast about refactoring some legacy code. You can check it out here:

    http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/05/06/pablotv-eliminating-static-dependencies-screencast.aspx

  • http://flux88.com Ben Scheirman

    I totally agree with the notion of questioning everything and always striving to improve, even if what you’re seeing is success (in your eyes).

    However, when you phrase it like “are you REALLY doing well? Really?” it makes you sound like a snake-oil salesman. This is actually true in practice when trying to sell TDD to someone who doesn’t think they need it.

    Sometimes I find it best to start small and convince them once they experience some pain that could have been alleviated with TDD.

    “You can’t heal what you can’t feel” — my CST said this and I find that it is so true.

  • http://16randombytes.blogspot.com Bill Barry

    It is like I am reading my own thoughts!

    A couple of notes though:
    It isn’t about TDD. It is about a functioning team that works well together and efficiently delivers exceptional software on a consistent basis. TDD is merely a means to the end (whether or not it is the best path is up in the air; it certainly works). This is why I put emphasis in code review and refactoring sessions. Code review gives the developers something to be proud of and refactoring sessions bring the team closer together. Both lead to a more maintainable codebase and more satisfied customers.

    On the third section: If you aren’t noticing the improvements, change. That is what agile is all about. Make sure you keep track of what you are doing and regularly reflect on it so that you have the opportunity to spot chances for improving. If TDD really seems to be holding you back, scale down on it: maybe you don’t need to mock all the interfaces, you can always create dumb stubs instead (sometimes it works better); perhaps you are finding it difficult to decouple your code (maybe you don’t have any tests and you are afraid to touch it because it works), simply go somewhere else (no one said you need to rewrite the whole application) and make small stabs at it.

  • http://creedcultcode.blogspot.com Dale Smith

    Hi Chad – your post inspired me to ask folks on my team what they thought about developer testing, since we just introduced the concept recently. Here’s what some developers thought, and what a project manager thought.