Test driven development (TDD) and pair coding have been part of my daily working life now - in both permanent and contract roles - for some years, and the benefits to me are clear.
However, it is also clear that they are not a magical panacea which cures all ills, and it is easy to get complacent and fall into bad habits.
I often meet developers who are less convinced of their benefits. Because of this, I find myself watching my work with an imaginary third eye of all the doubters. This causes me to take notice when I regularly see examples of how the output of myself and my team is enhanced by these practices, but also when we get it wrong.
I suspect the cynicism from other developers comes partly because they see the drawbacks without looking any further - although there is also no doubt that some people really struggle with the day-to-day reality of working so closely with their colleagues. It is worth bearing in mind that pair coding does not suit everyone - but a lot of people, after having a positive experience, will find they enjoy it or get more from it than they expected.
In this session I will present a series of short examples, detailing examples of when TDD and pair coding have not worked well.
These examples will be presented using a combination of actual code, diagrams and animations to explain problem domains and team dynamics, and lively anecdotes.
The code will be simplified, shown on the screen and encapsulated in such a way that the individual code and the wider context can be readily understood.
The session will also be interactive, with questions about:
The title of this talk is deliberately provocative. I won’t be arguing that people should not be using TDD and pair coding, but rather that they should use them with care. However, there’s no harm in drawing people’s attention with a catchy headline.
Clare Sudbery is a senior software engineer at LateRooms.com, and is active in XPManchester - both attending and leading sessions. She is a maths graduate with 16 years of software engineering experience, plus a few extra doing everything from full time novelist to secondary school maths teacher.
Five years ago she returned to IT with a sigh of relief after failing to convince stroppy teenagers that maths is fun. Since then she has embraced all things XP and still has to pinch herself to believe she could earn a living from having fun, solving puzzles and sharing the XP love.
She is on a mission to awaken the inner geek in clever women (and men) everywhere. She also has a blog, A Woman in Technology.
To buy tickets to see this fantastic talk, and many others like it head over to our ticket page.
Need help planning which sessions to attend? We've provided a breakdown of our various session types below.
A presentation and discussion of real-life (not theoretical) experiences of the application (or mis-application) of Agile and Lean practices. Case studies and experience reports include some discussion of lessons learned and an indication of how novel the work is.
Participants learn a new approach, tool or technology through using it to solve one or more practical exercises. Any software/hardware requirements are disclosed in the session description.
A session focused around some specific tool, technique or issue. Primarily led by the speaker, tutorials usually include some elements of interactivity or individual / group exercise.
An in-depth working session on a specific topic. May include paper presentations.