I recently read an blog post¹ describing a cognitive justification for test driven development. I think the topic is interesting. In doing TDD, there are a variety of reasons for why we write tests first, and it isn’t always to ensure correctne…

I’m sure with the number of users coming to AccuRev for help with managing multiple traditional and agile processes together (such as Waterfall, Scrum, FDD, Lean, XP, etc.), I’ll be able to find some over the months ahead. I’d like to capture their initial problems and ultimate successes both.

http://damonpoole.blogspot.com/2008/05/agile-case-study-litle-co.html

Alex

Breaking the expert mindset can work both for pairing and TDD. I’ve found a real (and constructive) tension between an ingrained habit of approaching problems by thinking about structure and pattern (blame the musician!), and the context-driven imperative of test-first (”this is what the code wants to look like” - thanks to Paul Dyson for this!).

I don’t think in either case this is guaranteed, though - we’ve all got experience of groups descending rapidly into group-think, and there’s no reason to believe that - if we write our tests first - the way the relationships and responsibilities in the code evolve will necessarily be that different from the last time we did it. In either case the onus is on the individual to allow themselves to be challenged out of their well-worn grooves - I’ll concede that promiscuous pairing helps (just so long as the nature of the pairing practice is understood by both, which is of course not guaranteed…) but fundamentally, individuals and groups don’t change without needing to, wanting to, and reflecting.

When you do TDD, the context is right there staring you in the face over and over again. Each change that you make is in the context of code you or someone else have written, and programming becomes more akin to sculpting or sensitive gardening, an activity where you have to look at what you have and make a decision about what to do next.

To me, that’s the core of it.. getting people to pay at least as much attention to what is there as they do to their ideas of what should be there.

This weekend I’ve been coding up an architectural spike of Twitter; I’ve got some notions about how to do things scalably that I wanted to put to the test. I had been thinking about it a bit during every (frequent) Twitter outage, and had some sketches in my notebook when I sat down to code.

As I did small incremental bits that solved immediate problems, I was definitely applying a variety of familiar patterns — albeit small ones — semi-instinctively. But because I had put my bigger designs out of my mind, the small pieces added up to a different direction than I was expecting.

It’s hard for me to know for sure, but I suspect the years of TDD practice have helped in two ways. One, they’ve trained me to attend much more closely to the code of the moment. Two, they have broken my learned responses into smaller pieces, more loosely joined. That is, I think TDD might have refactored the bits in my head similarly to the way it helped me refactor the various code bases.

Also, Jerry Weinberg point out to two interesting kinds of list - checklists and laundry lists.

Checklists checks, what should be present.
And laudry list gives you a list of different items that you might have forgotten, but that might just need cleaning up.

He also mentions that while working in complex, purely structured situations, laundry list may be preferrable.