The attendees of the 2007 QCon and the Øresund Agile 2007 conference could see how XP in general, and Test-Driven Development in particular came under heavy bombardment by the well known Agile profile Jim Coplien. Lean Magazine contacted the nowadays Elsinore-based software professor, currently working as an Agile Coach for the Danish consulting firm Nordija, and asked him to further explain why he seems to have such a problem with this part of the Agile movement.

Being devoted to Agile Development Jim Coplien is not against XP in general. But he has some problems in regards to its origin, and how some of its diciplines have been adopted by the software industry.
– The discipline as a whole has some goofy aspects, but many of its tenets are good – sometimes by accident, I think, and sometimes by design. For example, the Planning Game is a great step forward from Microsoft Project© hell, he says. But he thinks that some of the other practices are misconceived by many in the XP movement and often applied in a improper way. One of them being User Stories.
– Alistair Cockburn invented a concept called “User Stories” that were truly stories, which appealed to customers as a lightweight way to get them into the specification process, says Coplien. They were never designed to survive into the project, but were only a way to bootstrap into Use Cases. XP saw Alistair´s concept as a good, lightweight notation and ran with it. However, XP lost both the notion that User Stories should not survive into the project and that they should convey a story, and the new notion of User Story went beyond lean to skeletal.

TDD the problem child
But the main problem-practice of XP, according to Coplien, is Test DrivenDevelopment, and how some of its proponents perceive it as a design technique and that TDD in many projects replaces upfront architecture work. As Coplien pursued his critical scrutiny of XP in general and TDD in particular, he became alarmed about the patterns he saw. One pattern that emerged was that the projects would become “stuck” in about their third sprint or third release. Another pattern was that TDD projects would run
into lots of usability problems in deployment.
– One of these projects was a medium-size Java project using XP inside one of our large clients, remembers Coplien. They got really stuck in about their third sprint because they just couldn’t evolve the code any more. They hadn’t started with a vision of the overall system structure but instead had let unit tests drive the design. The tests were derived from user stories at hand, and the initial user stories gave a very single-dimensional view of what would necessarily become a complex system. You can push these users stories all the way through to code for a couple of sprints. But at the time of the third sprint the demands outgrew the structure that had been put in place, and the evolution slices tended to cut across the existing code in the worst possible way. They found they couldn’t implement new user stories without cutting across many existing class boundaries.

Refactoring hell
The problem, according to Coplien, was that the system lacked an overall structure that anticipated the general user stories that even the most basic version of the system had to support. TDD forced them to build one method at a time (”That’s all you can test!”) in a methodology that gives no place to big-picture thinking, architects, architecture, domain expertise, or knowledge of how past systems had been structured. Further, TDD caused them to focus on methods (”That’s what you write tests for, and those are the focus of coding under TDD!”) which in turn led to a bottom-up procedural architecture. They had written bottom-up FORTRAN in Java syntax, wrapped in some classes whose identity and partitioning came from somewhat arbitrary customer whims.
– True to the XP mantra, the team told management that they needed to undertake a re-factoringexercise … though they presumably had been doing continuous refactoring all along – hey, that’s what it means to do XP, right? says Coplien. Management gave them leeway to do a refactoring sprint. And the project was able to pull itself up by its bootstraps and deliver to the market. That was over a year ago. The last I heard, they were again in the middle of another three-month re-factoring exercise. This was just one of several projects where we observed this problem. I’ve polled quite a few well-known ScrumMasters in the industry who have seen similar failures in or around Sprint 3 of a project using XP practices.

GUI problems
The other problem Coplien wants to address is unusable human/ computer interfaces.
– I first saw this in GUI-intensive projects I was working closely with, and which were also using TDD and XP. The interfaces had many surprises in them. The problems appeared as modal screens, as screens that just left users puzzled, and in growing numbers of user input errors. According to Coplien, the problems can again be traced back to the procedural nature of the design and the lack of sound consideration for the domain objects that live in the user’s mental model of the world. TDD fails to create objects that shine through to the interface and match up with the user’s conceptual model of the world.
– Kent Beck used to say that a good interface cannot hide bad code, and that’s what’s going on here: the code is bad because it doesn’t reflect the user worldview, and it comes to be bad because it was created one method at a time at the mercy of low-level tests.

Universal mistakes
In spite of all their advanced knowledge and professional skill, software developers tend to make the same simple mistakes as people have done through all ages:
– I think a lot of Computer Science history follows a litany of old proverbs: the newer, the better; the grass is greener over on the other side; I don’t know where I’m going, but it’s better than where I’ve been. Such reasoning can have and has had serious consequences. I think we too easily ignore these consequences, and certainly their causes. If we are to learn as a community, we need better to understand them.