Tag Archives: design

what’s the london school of tdd?

I’ve been hearing about the London school of TDD, and I’m puzzled. This post by Jason Gorman was helpful, but his examples confused me.

In describing classic TDD (as in TDD by Example), he uses as his example a program to express integers as Roman numerals. Then he gives an example for London school (as in Growing Object Oriented Software Guided By Tests) that is bigger, more complex. I’m not sure how to compare them.

I’m wondering whether London-style TDD provides the same advantages as classic TDD. From Wikipedia:

TDD can lead to more modularized, flexible, and extensible code. This effect often comes about because the methodology requires that the developers think of the software in terms of small units that can be written and tested independently and integrated together later. This leads to smaller, more focused classes, looser coupling, and cleaner interfaces.

I’m just starting to read the second book; I’ll know more as I get into it. But I’m really curious: does London school take the same sort of tiny steps that classic TDD advocates? Does it retain the benefits of TDD? I figure you get test coverage, but do you also get emergent design? Simple* design?

* See the four rules of simple design, as explained by Ron Jeffries.

Do complex projects need design up front?

“Agile purists”, Bob Customer says, “don’t understand my reality. Nobody ever tells me how agile says we’re supposed to manage the overall architecture.” Without an orchestrated design process resulting in thorough design docs, how could we keep all the disparate pieces together?

What does Agile tell us about big projects with lots of little parts?

GeePaw sez…

Bob, the best way to manage a large project is by continuous interaction between teams and between teammates while coding proceeds according to a work-in-progress-limiting scheme.

Skilled rhetoricians constantly invoke “painting yourself into a corner”, or “the local optima problem”, or they just sometimes jump out and say “BOO-GA BOO-GA BOO_GA!”

This scare-mongering is effective because we all know large complex software is risky, and we all wish we knew some way to make it safe. Architected projects are no more likely to succeed than un-architected ones. Two thirds of all large projects (>1 year), ship 6 months to a year late. The other third never ship at all.

Sometimes you just have to live with your fear for a while. Certainly, utilizing mechanisms that have never succeeded will cost you a lot without helping.

Don’t worry, though. Once you’ve nailed that first big project using agile technique, you won’t have to be scared of them ever again.