Quality, Test Driven Development and Technical Debt

I really liked Mishkin Berteig’s recent post on why quality is not negotiable, especially the reference to paying interest on technical debt:

“As you accumulate debt, you have to make interest payments to maintain the debt. This shows up in the workarounds, the design cruft, the inelegant solutions, and ultimately in the slow down of the team in implementing new features.”

This is a great way to explain to the business why we’re investing time right now in becoming more Test-Driven.

Agile 2006 – my highlights

Over the last couple of days, I’ve spent some time collecting my ideas and thoughts following Agile 2006. Spending the time to reflect has really helped to tie up the loose ends that were hanging around in my head, at least the ones from last week. I’m glad I took the good advice to stay away from email, well as much as possible, because for the first time in a while I’ve really got into “the zone” and it’s been incredibly productive. So here’s a brief summary of my highlights, and for a summary of all of the sessions I went to, check out the Agile 2006 page.

I went to so many worthwhile sessions, it’s hard to pick my favourite, but three in particular really stand out:

Ron Jeffries and Chet Henderson’s Planning Game – this session is great for two reasons: firstly, it’s fun and entertaining, and secondly, the lessons just reveal themselves through the game: to the most value from an agile project , you need to have clear estimates for the stories, you need to know your velocity, and the business needs to assign a clear value to the stories. Armed with this information, you can get almost all of the project value in the early iterations. Combine this with small, frequent releases, and then you start to see the real value of being agile and iterative. Ron and Chet have performed this session a lot, and it shows. It really is a performance, the banter and role playing were fantastic, especially in the Management role. If you haven’t done this, and you get a chance to, do it.

Programmers are from Mars, Customers are from Venus – Angela Martin and Robert Biddle – this was a highlight for me because it had some really practical, relevant guidance on splitting up the role of the customer into nine separate roles with specific different responsibilities – including acceptance tester, UI designer, negotiator, diplomat, and technical writer. They also suggested techniques such as having programmers play customer apprentice to improve interaction, and having a customer counselor for those times when you just need to vent. The powerpoint is really simple and clear, and it was good to attend a session that really focussed on and sympathised with the customer, rather than the team. I don’t play the role of customer, but it did give me a much deeper understanding of why it isn’t always as easy as you think.

The Test-Driven Development Pairing Game – Peter Provost, Mitch Lacey, Brad Wilson – this was the one session I refused to miss, and I’m glad I went, even though I had to leave Diana Larson and Esther Derby’s session on retrospectives, which I was also really enjoying. Brad and Peter have a great energy and humour, and they’ve created their own way to productively get the better of each other. Anything that makes writing unit tests fun for developers is pretty impressive, and their solution to write a single test and then pass the keyboard so that the other person makes it pass seems to go some way towards doing that. They somehow demonstrated something that combines two fairly complex practices in a really simple, easy to understand way, and entertained a group of people while simultaneously writing clean code. That’s pretty impressive. I’m just hoping that when I demonstrate it back home, it will seem as easy.

The biggest highlight of all was just meeting and talking to so many people who were doing agile – people who were still experimenting, who were learning from the same mistakes I am, and people who’d done it over and over and could share their experiences, or had the patience to listen to mine and offer advice. Over the next few weeks I hope I can share some more of my own experiences as I try and put some of these things into action!


Agile 2006: The Test-Driven Development Pairing Game – Peter Provost, Mitch Lacey, Brad Wilson

Thursday 15:30 – 17:00


A new twist on pair programming that combines test driven development, or test driven design, with pair programming to create a game.


This was the only session of the entire conference that I had decided in advance there was no way I was going to miss. I’d heard about the technique and was really interested to find out more so that I could take it home. I wasn’t disappointed – Peter and Brad have so much energy and passion, and their constant banter made the session really entertaining.

It was a live demonstration, and the application they chose to demonstrate it (building a simple bank account object with unit tests) worked really well – I intend to use the same idea to demonstrate back to my team.

There are three legs to the development “stool”:

  • Test driven design
  • Real time code review
  • Refactoring

Developers want to get the most out of their time, and traditional pair programming can be boring for the navigator. The driver is the tactician and the observer should be the strategist, but in practice they are often thinking about email, lunch, or what they’re going to do next.

TDD evolves the design of the system. In TDD, a test is written before writing the code, then just enough code is written to pass the test, then the design is improved: write – run – refactor.

Refactoring improves the design without changing the functionality. If more tests are necessary, then it’s not refactoring.

In the TDD Pairing Game, the keyboard is passed at every step, which means it goes back and forth very rapidly – each step should not take more than 3-4 minutes. The pair negotiate over disagreements, so it ends up being a process of negotiation. The test writing drives the design.

  • Step 1 – write a test that compiles, but doesn’t pass. Pass the keyboard.
  • Step 2 – write enough code to make the test go green. Pass the keyboard
  • Step 3 – either write another test, or go back and do one refactoring.

The rules of the game are simple:

  • If the test light is red, the next step must be to make it go green.
  • If the test light is green, choose whether to write a successful test, a failing test, do a refactoring, or stop and think strategically about the system design – use the whiteboard to diagram it, etc.
  • If the system doesn’t compile, the keyboard can’t be passed.
  • Don’t write too much code. Throw exceptions if things are not yet implemented. You’ll be surprised where it leads you if you don’t write too much code.
  • One test at a time to evolve the game.
  • No email, no phones with email, no IM.
  • It’s recommended that developers should check in as much as possible – at every green light, if it’s cheap enough. Source control is a big giant undo button.

Tests have three separate code “paragraphs”: arrange, act, assert. Set up and teardown are considered evil – factory methods can be used instead. Whether we unit test edge cases or not, is a design question.

Ideas for new tests are kept in comments in a list, which evolves as you start coding. If a test gets too big, comment it out, then go back and refactor.

Recommended further reading

Avoid Setup and Teardown – http://www.agileprogrammer.com/oneagilecoder/archive/2005/07/23/6261.aspx

Agile 2006: Agile Testing – Brian Marick

Sunday 16:15-17:00


One role of an agile tester is to ask questions and catch the error and exception conditions. Testers generally focus on what goes wrong. They have a familiarity with bugs, they look at bugs, learn from them, and generalize. In agile projects, developers should get better at anticipating bugs.

With test driven development, the UI can be created, then the logic implemented. In test driven development, the sequence is:
Write a failing test -> Make it pass -> clean the code.

Cleaning the code is very important.

Exploratory testing or rapid testing is another form of agile testing.