Home » TDD » TDD Gamification – Turning Test Driven Development into a Game

TDD Gamification – Turning Test Driven Development into a Game

ge-gam-018When I was in college, there were some guys I hung out with who played this game called “Questions” which they got from some book.  Actually, it was a play.

Anyhow, the basic rules are:

  • You can’t answer a question with a statement
  • You can’t hesitate or make a false start
  • You can’t repeat a question that has already been used
  • You can’t ask a rhetorical question
  • You can’t ask an unrelated question.

There was also this podcast at DotNetRocks where they were talking about a beer app and how they had added game elements to the app by adding badges for various types of beer to get you out of your comfort zone.  Maybe there is one for “My first beer that I liked” because I’ve yet to find something I like.  But give me a good Merlot!

All of this got me to thinking about how we might turn Test Driven Development into something of a game.

There are several people who have already addressed the Gamification of TDD

TDD and the Gamification of Testing

This article talks mostly about how TDD has many elements of good gaming inherent in it.

  • Because it makes testing more like programming.  Well, what he actually says is that it raises testing to the level of complexity the programmer is familiar with.  But in reality, I think this is because it makes testing something that can be coded.
  • Because TDD is measurable.  The test either succeeds or fails.
  • Because TDD gives you immediate feedback.  Or at least a well written test gives you immediate feedback.

TDD: The Gamification of Programming

This article provides an interesting perspective of someone trying to program using TDD for the first time.  You get the normal complaints, like “this takes too long” along with acknowledgement of some of the benefits.  But what he realizes is that the process has made programming more like a gameThe process of using TDD make programming more like a game than about the creative problem solving most of us got in to programming for in the first place.

Gamify TDD

This is the first article I found that, instead of saying that TDD is already a game, like the two above, actually ask how we might formally turn TDD into a game because it already has many elements of a game.  But he never actually says HOW he would do that.

TDD Gamification

Putting this all together.  Here is how I would actually make TDD into a game. Here is how @davembush would turn TDD into a game.

The rules:

  • The game is played in pairs.  (Paired programming)
  • Game starts when programmer 1 writes the first test.
  • Once a failing test is written, programmer 2 writes JUST ENOUGH to make the test succeed.
  • Once a test succeeds, programmer 2 writes another test, and programmer 1 writes just enough to make it succeed.
  • Play alternates until no one can think of another test that will force more code to be written.
  • Programmer loses points if he is caught writing more code than is necessary to pass the test.
  • Programmer loses points if he is caught writing code that has dependencies embedded in it.
  • If a dependency is required, the test writer and the code implementer will collaborate in the method of dependency injection to be used.
  • All points lost by one programmer go to the programmer who caught the mistake.

Embellishment:

If code is found to have a bug in production, both programmers responsible for the code loose a point, regardless of how many lines of code are impacted.  One point per recorded bug.

I’m assuming that most shops have more than 2 programmers.  On any given day, programmers would be paired up for the day of programming.  They are responsible for turning out bug free code.  Because we are tracking the code over the long term, we will be able to see just how effective each programmer is at eliminating bugs.

In fact, if you are in an environment that can’t quite stomach having your programmers paired up, I would suggest keeping track of the code that wasn’t done under the game.  This would be the “house score” compared to an individual programmer’s score.

The only thing we have left is some way of being able to account for productivity.  I mean, if I write no code, I’ll have no bugs, right?  And all things being equal, the more productive I am, the more bugs I’ll have.  So how do we measure this?

Here is what we can’t do:

  • Lines of code – you can’t measure based on lines of code because that has been shown to be an inaccurate measure of productivity.  More lines may just mean you are not very efficient.
  • Hours worked – Rapid Development has statistics in it that show there is a factor of 10 difference between good programmers and bad programmers.

Just a suggestion:

Since short methods are desirable, what if we measure number of test relative to number of methods relative to number of classes.  This would enforce the single responsibility principle.

T = Tests

M = Methods

C = Classes

1/((T/M)/C) = Productivity Score

Therefore,

  • If I worked on 3 classes each with 6 methods and each method has 2 tests, I end up with a productivity score of 1.5
  • If I had one class with 18 methods each with 2 tests, I end up with a productivity score of .5
  • If, on the other hand, I put everything in one method, and one class and had the same 36 tests, my productivity score would be .02
  • If you write no code, your productivity score is 0.

That’s just a simple way to calculate.  You may choose to use cyclomatic complexity in some way if you have that number easily available to you.

Well, that’s my rough sketch of how we might be able to turn TDD into something of a game along with being able to prove to ourselves and management that it really does produce better code.

How else might you embellish this or change it so it works better?  Let me know in the comments below.

Other Test Driven Development Resources

 

Other post in TDD

Related Post

  • The Parable of The Road Line PainterThe Parable of The Road Line Painter Way back in the day when lines were first being painted on roads.  The early lines were painted by hand.  In those days, a painter was hired and given a stretch of road to […]
  • Test Driven SpecificationsTest Driven Specifications Several years ago, long before the community was actively talking about Test Driven Development, I worked for a short time at a company as a “bug fixer.”  That was my role.  They […]
  • “Debbie-Done”“Debbie-Done” A long long time ago, in what seems now like another world, I worked for a company as a Clipper programmer.  While I was there I heard this story about a lady named Debbie. I was […]
  • Limiting Beliefs of ProgrammersLimiting Beliefs of Programmers At the risk of making half of my audience think I’ve gone off the deep end, I’m going to address a topic that I’ve only recently REALLY begun to understand, in part thanks to Soft […]
  • TDD Saves Time – A StoryTDD Saves Time – A Story I recently had an experience writing code that proved to me, once again, that using Test Driven Development really is faster than the way I have been working.You will remember a couple […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.

3 Pingbacks/Trackbacks

  • Pingback: Dew Drop – April 23, 2015 (#1999) | Morning Dew()

  • MCodeMedia

    please no! Stop it! We are here to code! JUST SAY NO TO THIS!!

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1847()

  • Pingback: Automate the Planet()

  • Tiberiu Tofan

    This game is called Ping-Pong Programming and it’s over a decade old. Adding scoring to that seems like cutting all the fun. Programming (and more so XP) is not a competition, it’s collaboration.

    • Yep, it has been around for a while.

      I don’t see competition and collaboration as mutually exclusive.

      If you already have something that is working for you, I’m really happy for you. Unfortunately, you would still be in the minority. My intent in writing this article is to provide some incentive for others to do the same and by adding in the scoring, keeping them focused on clean code in the process.

      • I love ping-pong when we do Coderetreats and Coding Dojos – it is a great and fun way to make people try TDD.

        I actually like the idea of scoring as well. Just not like this. Make it a team activity, not a competition between partners. Both people should get the points.

        We have tried TDGotchi: http://www.happyprog.com/tdgotchi/ and its fun 🙂 There are other similar ones as well.

        It will give you points for red to green and refactoring and lose you points for red-red. So it forces you to work in very small steps.

        • I like the small steps idea.

          This was just an idea. Use what works. I know some teams who would invite the one on one competition. I can see there are others who would not. It is a small part of the scoring, so personally I don’t think it makes much difference in the long run if you use it or not.