More on Quality

I started typing a comment to John Teague’s post about Creating a Culture of Quality, but it got a little long so I decided to make it a post. If you would be so kind, please read John’s post first (linked in the last sentence) and then proceed with this post.

Here are some of my additional thoughts:

  1. There are three over-arching principles that form the basis for everything John said and what I’m about to say:  1.) Fast fail  2.) Quick feedback cycle and 3.) Automate it.
    1. Fast fail – To John’s point (‘Make it Easy’), fast fail is crucial to avoid a long delay between change and corresponding failure. If something is wrong and it’s detected, fail ASAP so that it can be fixed. Don’t allow problems to persist.
    2. Quick feedback cycle – Whether it’s a success or failure, I need to know very fast (minutes, not hours).  If your build/test cycle is necessarily long, consider breaking it up and doing the fastest, most critical tests first and then doing the lengthy setup and tests as part of a cascading build that only happens maybe a few times a day.
    3. Automate it – Whatever you’re doing for quality, try to automate it to the maximum extent possible. Leave the team and any future maintainers with automated paths to success. Eliminate magic and bubblegum/tooth picks/duct tape in your process ASAP.  These things will continue to creep up during your project. Be vigilant and constantly scan for and eliminate them every time they appear.
  2. Automate as much as possible. If you’re doing anything manually more than just a few times, you’re a.) wasting time and b.) introducing variables and instability into the process that could and should be automated.  If you think it’ll be hard to automate, but you plan on doing it manually more than a few times, I’ve observed that it’s always cheaper to bite the bullet and automate. Anyone who has doubts about whether quality-first (i.e. TDD, BDD, etc) slow down a project, I can tell you that you’re worried about premature optimization because I can guarantee that on most projects, MUCH more time is being wasted in other areas than would be affected by TDD/BDD/etc.

    The interesting thing here is, though, that you probably don’t realize how many things that you’re currently doing manually that could be automated. Until I was on a team with someone who was automation-infected (Jeremy Miller), I didn’t realize just how much time I had been wasting doing things that I didn’t think were automatable!  (side note: I plan on blogging more about real-world examples of this in the next few months, so if you’re thinking ‘This guy is BS’, please check back later)

  3. Add tests for conventions and tribal wisdom types of things. If you hear team members saying “Everyone:  Please make sure that none of your controllers have a method called Floogle() because that will mess up XYZ”, this should be a big clue.  Sure, that’s a contrived example, but you know what I mean.  Anyhow, add tests for these to enforce that convention.  When new developers come onto the team and don’t yet have the tribal knowledge, they’ll be protected from harm this way.  When the convention tests break, you have to make the choice to change the convention or fix your code.  Changing the convention requires everyone on the team to be aware and in agreement.

    For your reference, Glen Block was working on a project with Ayende and they both wrote about a situation where they did this and it worked out really well. You can read Glen’s Post and Ayende’s Post at their respective links.

  4. John Teague mentioned this in his post, but I want to reiterate: Don’t get too focused on coverage.  Tests should enforce that the code does what it should and, in most cases, not necessarily that everything is perfect. Use tests to help you flush out design issues. If tests are hard to write: design smell.  If lots of tests break  when you change a small aspect of your design, that’s either a design smell or, more likely, a smell that your tests are too brittle and too envious of the code.  Tests should be there for ensure that the basic requirements and acceptance criteria are met, not to make sure that every line in the code actually executes (which is a common TDD beginner mistake — I did it a lot ;) ).  This is why I tend to shy away from code coverage as a metric because it tends to encourage code envy from your tests.
  5. No one leaves the building without having committed their code for the day. If the code’s not ready to integrate, then create a branch and commit it there. Don’t walk out with your laptop and then drop it and lose a day’s-worth of work. Frequent checkins is a must, must, must!

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 Agile, Mangement, Principles, Quality. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
    • http://expectedresults.blogspot.com/ Phil Kirkham

      Interesting article, I hope you follow through on your “plan to blog more about real-world examples of this in the next few months”, I for one will be looking forward to reading about this

    • Jeremy Gray

      Agreed on all points except #5.

      Frequent checkins are a must, but not the kind you described in #5. If your developers cannot check in good-to-go code on a frequent basis, you have a work decomposition problem.

      As for checking in on a branch, remember that your version control system is not your backup solution.

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

      @Jeremy:

      RE: Checkins: Sometimes you do have multi-day refactorings. It shouldn’t be regular thing, though. Like you alluded to, you should avoid situations where your work spans more than one day before you can commit.

      RE: Branches: That’s kind of the point of branches, right? Make sure you merge them back in ASAP expect in a prior-release branch (i.e. the release_1_1 branch for ongoing maintenance of the currently-shipping 1.1 release where Trunk is the soon-to-be-released 1.2 current codebase)

    • Jeremy Gray

      @chad – I just wrapped up a multi-day refactoring. To avoid violating our rules about never breaking the build, which includes passing all unit tests and meeting all coverage requirements, this was done without checking during a three day period (whereas I normally check in many, many times per day.) I would have considered this a work decomposition problem if not for the next two alternatives allowing more incremental check-in but inflating the effort by at least 2x or even 3x.

      My own version control and light backup strategy in this particular situation was to create patch files. Had I expected to take longer on this I would have broken out some distributed version control layered on top of our primary version control or perhaps cut a single-developer experimental branch (which we try to avoid doing because it let people break our rules about not breaking the build, as all branches must have build automation and the build must never break for any of the reasons I noted earlier.)

      I’ve been using version control systems for a good fifteen years now and I still have yet to see good justification for treating version control as a backup solution and/or allowing people to make non-atomic and/or breaking commits against the repo. After fifteen years of conflation with backup strategies and work decomposition problems, it gets a little tiring. ;)

      I keep things simple for my developers: Commit frequently. Commits must be atomic and never break the build in any of the possible ways. Decompose work and coordinate and collaborate with others to achieve this. For comfort beyond the limits of work decomposition, talk to IT about backup and/or layer on personal versioning (via patches, dvcs, whatever.)

      That I haven’t needed to alter the above in fifteen years says something, IMHO.

    • http://ferventcoder.com Fervent Coder

      Dude! I wholeheartedly agree with all of this. I am also an automation freak (and a code reducer, but that is another topic).
      Automate the whole process and have someone click a button or two at the most and bam! You have a fully deployed environment set up and ready. I plan on blogging soon on some of our automation stuff I think is pretty sweet. It seems everyone is talking quality lately.

      I didn’t even notice, but I did the same thing because I had a topic in the queue that was really itching to get out there. Then I started reading through my feeds and I am not the only one on this quality kick. Too awesome! :D

      http://ferventcoder.com/archive/2008/06/11/develop-for-maintenance.aspx