What open-source projects have used TDD and either got test-induced design damage or used TDD well? (from Mike Harris)

David:
One of the problems of debates like this is we can’t give URL examples. Techniques that can’t be illustrated with just a couple of lines of code don’t have good shared context. The open source world is really good at producing libraries, adapters, wrappers etc but much less successful at fully fledged applications. Open-source contributors often work on private applications and open-source common frameworks and libraries. Going into discussions with different contexts often makes it look like there is more disagreement than there really is. People come together when you have real code rather than philosophical principles. You can understand people via presentations – which is why David used Jim Weirich’s example for design damage. For good rails code read any Rails book showing standard testing approaches.

Martin:
It takes lots of time and effort to understand real code and even then it’s not the same understanding as you get by being part of the team that’s working on it.

Kent:
JUnit is an example of a project that used TDD strictly and turned out well. But it isn’t a good example for this discussion because it has clear interfaces that make a sweet spot for TDD. We are talking here about different kinds of applications. If someone has a good example, write it up.

David:
We can’t treat programming as a science because we can’t evaluate techniques objectively, but this doesn’t mean it isn’t worth debating. We can’t get a definitive answer, it’s your job to figure out what makes sense.

Kent:
We can’t replicate experiments, but we still can look at things personally with a scientific mindset. We can try things out empirically for ourselves, but you can’t get universal answers.

What could change about the way we write software to make TDD redundant or obsolete for Kent and Martin and what could change about how TDD is performed to make it useful for David? (from Graham Lee) 

Kent:
RIP TDD post points out his position. TDD solves several problems, starting with confidence and enables breaking problems down piecemeal, tackling specific cases without having to solve the general case all at once. It’s also a comfort to know you don’t need to solve the whole problem in one go. Don’t give up on TDD just because it’s hard.

Martin:
It’s not about changes that would make TDD obsolete, rather the applicability of TDD in different contexts. Following TDD in a mechanical way with a calm “rapid unhurriedness” can lead to good designs. Most of my programming these days is my website toolchain and while I do piecemeal progress, and have a good regression test suite – I don’t find TDD applicable. The infodeck code has lots of application behaviour where TDD was effective. Some contexts are more suitable for TDD than others. And people bring their personality into that context.

David:
My introduction to testing was through TDD, I liked it and tried to apply it to everything but slowly realised that lots of areas in an MVC web application didn’t feel good for TDD. This doesn’t mean TDD isn’t effective for some situations, just that those cases are a small percentage of the work. But abandoning TDD doesn’t mean I want to give up self-testing code – that’s always been the value of TDD.

Martin:
This is exactly how someone should take on TDD (or any technique):

• Try it out
• overuse it
• settle into a mode that works for you

Kent:
I don’t mind where people end up with their workflow having done this kind of process. My experience of using TDD differs from David’s. There are moments in development where something is hard and he gets an idea of an object with a certain protocol that simplifies things. TDD is a mechanism to quickly get feedback on such an idea, trying and example usage of the API and implementing it. There are cases where TDD doesn’t fit. Command-R is a good way of getting feedback: just reload the browser and see if it looks good. But I’m hoping for the moment when I can see the simplifying object and try it out with TDD.

How does a lack of design experience affect TDD and how does TDD work with an inexperienced developer? (from Tudor Pavel)

Martin:
TDD forces people to do small pieces and helps them separate interface from implementation. It doesn’t guarantee great results: you can’t do good design without experience. When less experienced people do TDD they typically don’t refactor enough, leading to sub-optimal designs. You can’t compare an inexperienced developer’s output to an experienced developer’s output, you have to compare it to what that inexperienced developer would have done without TDD. Although we can’t measure this, based on new developers at thoughtworks, it does seem to be advantageous, and creates a self-testing code base which is easier to improve later through refactoring. Tests are required in order to refactor the code safely.

David:
I found TDD was a great set of training wheels, but the discussion didn’t move on enough since. Some people felt that a nuanced discussion of TDD would “confuse the young ones”. I’m always skeptical when people say you must give simple, direct, bombastic advice to new people otherwise there’s no way they would do it. That shows a lack of confidence in what you’re teaching.

Martin [35-36min]:
I agree in that dislike for dogmatic statements. I get suspicious if I can’t find arguments against something I’m describing. One twist, however, is that we do have to keep repeating introductory stuff for new people. There’s a lot of new people coming into the profession. It’s inevitable that we have to keep repeating the basics for new individuals.

David [36-38 min]:
Over the last 10 years or so, many developers have added their own 2 cents to TDD and mutated it into something away from the original principles of TDD. Sometimes you need a reset button. This is where I’m coming from with TDD is dead. We need to go back to first principles so ctrl-alt-delete and wipe out most of the stuff we’ve built on top of it.

Kent [38-40 min]:
My gut reaction gut reaction to David’s original keynote was at that level. Programmers will often do the same thing many times, make things too complicated, and stick with dysfunctional systems at work. I’m happy to reboot to first principles, but don’t want to lose the evolution of people’s expectations about programming in the last ten years. You should be able to feel confident, point to progress, have productive technical collaborations.

David [40-42 min]:
I think that several things came together at the same time : TDD, XP and object oriented programming languages like Ruby. People laughed at the notion that programming should be fun, but he wanted to continue with that notion with Rails. Now he thinks that the Ruby world takes that happiness for granted – these things have won – as has Agile. Martin is shaking his head…

Martin [43-44 min]:
I disagree that agile has won – the label has won. There are a lot of people talking Agile but not necessarily doing it. This is typical for things like this, a process I call semantic diffusion. The big win is that now we are able to do Agile openly at clients, but we have a different set of problems with lengthy mandatory “Agile” processes at some companies.

David [45-47 min]:
I’ve seen this reboot problem with other things – after 10 years you get lots of cruft. Pinkberry, a frozen yoghurt company, started with just two flavours and was very complicated. 10 years later but then got an over-complicated range. TDD and Agile are very broad tents now. Under the same broad tent people who say they are doing Agile are doing opposite things to others who are saying they’re doing Agile.

Kent [48 min]:
I haven’t seen the problems with TDD that David has. I always applies TDD from first principles in his work. I appreciate that David has brought attention to TDD acquiring some barnacles and needing some scraping.

David [49-50 min]:
I’ve seen similar issues with Rails. I use it based on first principles and am sometimes shocked by some Rails usage. Why are you making things so hard on yourself? This is not good, how could you get here? This is almost not recognisable.

Kent [51 min]:
I remembers the first OOPSLA when XP got attention, Jim Rumbaugh said you won’t recognize what happens to XP in 10 years and he was right.

Martin [51-52 min]:
Oddly enough this is what success looks like, the alternative is that things don’t take off. It’s always hard to tell if something bad happens due to something inherent in a technique or due to misuse of a technique. As you have more success you have more semantic diffusion. All we can do is keep repeating the basics and the good lessons.

David [52-56 min]:
“you either die a hero or live long enough to become the villain.” This is an inevitable process. Ruby was a reboot of good ideas about programming. Functional Programming is another reboot. These reboots are healthy. I’m impressed by how long Rails and TDD have lasted. Success looks like becoming the villain. Before Rails I worked with PHP and a lot of people were saying it was terrible. I said if you use it right it’s actually great. You can write good code with PHP if you use it well, but other languages do a better job of encouraging good usage. PHP developers say you don’t have to use the bad parts and can right beautiful PHP code. I think using TDD well in an MVC web app is even harder than writing clean PHP.

Kent [56-59 min]:
I haven’t found that – any time I can break off a piece of a problem into a useful abstraction I can use TDD. I want to explore other avenues to these big goals of bringing his whole self to programming. I’ll continue to explore this with experiments: doing it too much, not enough, finding the goldilocks zone, and understanding why. TDD isn’t dead, but I’m glad David set fire to it so it could come out like a phoenix.

David [59-65 min]:
I started this discussion because people wouldn’t talk about the cases where TDD wasn’t effective because it wasn’t politically correct. They weren’t feeling good or confident, but were told they must use TDD or they weren’t being professional. Developers had to do it because “its just how we do things around here”. He wants to open the sphere of acceptable reactions so we can discuss when TDD is and isn’t appropriate. Lots of people on the internet talk about how good TDD is, but people were afraid to say it wasn’t working for them. Some job adverts even say you must be doing TDD or don’t bother to apply, which is like saying you must have 10 years of Rails experience. For me the baby is self-testing code, we don’t want to lose that when questioning TDD.

Martin [65-66 min]:
We agree on many things. Without having the chance to work together we don’t know how much we actually disagree. Kent and David have a lot of similar aesthetics with software development. You can’t take any technique blindly. We have to work through our own experience.