Loading ...
Sorry, an error occurred while loading the content.
 

Introducing TDD (was: Creating new bugs when fixing old ones...)

Expand Messages
  • Anthony Williams
    ... At the employer I ve just left, I ve been trying to introduce TDD for about the last 18 months, since I found the benefit of it. All my code on new
    Message 1 of 1 , Aug 5 2:16 AM
      Matt Secoske <secoskem@...> writes:

      > Any tips for enlightening those people who are not interested in getting it?

      At the employer I've just left, I've been trying to introduce TDD for about
      the last 18 months, since I found the benefit of it. All my code on new
      projects, and most of my code on legacy projects has been written TDD, which
      is a good start, and I successfully convinced management to introduce
      automated acceptance tests on several projects. However, I was largely the
      only one doing TDD. At every opportunity (such as when customers complained
      about bugs), I raised it as a suggestion, but to no avail. Initially, I tried
      arguing, trying to convince the other developers that TDD was "the one true
      way", that would solve all their problems. This just made them more
      argumentative, and entrenched in their anti-TDD stance.

      After reading many posts on this newsgroup, I changed my tack. Rather than
      advocate TDD in a forceful manner, I said things like "this gives *me* more
      confidence in *my* code", and so forth, making it about the benefits that I
      found, rather than attempting to force my will on theirs. This definitely got
      a better reception --- more discussion about the topic rather than staunch
      adversity. I also found it beneficial that customer reports were positive.
      The new software I developed using pure TDD was essentially bug-free; some
      people didn't like the way some of the features were implemented, but
      everything worked as intended. The new versions of software I developed were
      praised by customers and the sales department as the most stable the company
      had ever released. This had the effect that people were more interested in
      what I had to say.

      I was appointed mentor of one of the junior developers, and he soon took up
      TDD, once he saw how I was benefitting from it (and because I kept badgering
      him to write tests) --- he is also now at a new employer, and has asked me for
      advice on setting up a unit test harness, so he definitely "got it".

      Some of the other developers have also started adding the odd unit test to
      their code, but not TDD. However, the other day I had the opportunity to pair
      with one of the other developers --- he needed to learn about one of the
      projects I was working on, and we were trying to add some new
      functionality. This was a novel experience, because we didn't do pair
      programming either --- in fact, it was rare to have more than one developer on
      a project.

      Because it was my project, we did it my way --- TDD. The other developer had
      never worked that way, and found it strange. However, he did comment to me
      after the first day that although he was finding it hard to get his head round
      working that way, he had noticed that we hadn't actually fired up the debugger
      once all day. We paired on this for a couple of days, and he seemed to be
      getting it, but I don't think he'll use it on his projects without further
      impetus, something which I can't really give, now I've left the company.

      Here's a summary of what I learnt from that experience:

      * Don't argue. Don't try and force TDD on people, just explain the benefits
      that you see, on your code; make it personal to you.

      * Work closely with people, pairing if possible, to *show* them the
      benefits.

      * Do it on real projects if you can, so you can look at real results --- it
      feels good when customers say "the latest release is marvellous, it's the
      most stable you've ever done", and being able to point to that and say "this
      release was done using TDD" is good support for your stance.

      * It takes time for people to get used to the idea. Don't expect to do a
      presentation, and then everyone start TDD the next day. Be prepared to
      explain and demonstrate several times.

      Anthony
      --
      Anthony Williams
      Software Developer
    Your message has been successfully submitted and would be delivered to recipients shortly.