"You just gave a talk where you highlighted the importance of the user interface and of domain knowledge. And you had to tell them that!", from Jim Coplien's blog post
I'm a few months late seeing this one; the recent InfoQ debate between Uncle Bob & Jim sparked this entry.
It's been a number of years since I regularly have participated in the Agile community. I used to be on Wards' Wiki quite a bit, managed to get quoted in a book, have been branded a pain in the ass by P(i)MPs , yet I have had some reasonable successes with XP and SCRUM techniques in the past.
First, a sobering observation: Having worked at BEA the past 3+ years, and seeing a large cross-section of financial, telecom, and government organizations in the U.S. and Canada, I will say this: the vast majority of development is still not Agile. (This is an obvious corollary of Online Rule #1: "The Internet is Not Reality".)
IMO, the big reason has nothing to do with the merits of agile, it has to do with the cycle and politics of annual capital budgeting combined with the process to actually use the funds once they've been budgeted. The agile-way of incremental funding, value-based pricing, and continuous improvements are about as foreign as anarchism to some business executives. It doesn't help that many CIOs I've spoken with believe that Agile is just a rebranding of James Martin's Rapid Application Development (RAD) from 1991. There are some CIOs that really do get it, but even he can't coax his bifurcated organization down that path easily.
Second, there is a part of me that is glad that many have not adopted Agile. They don't have to deal with the ridiculous religious posturing that goes on with regards to TDD, architecture, and design.
I have never bought the idea that the design would fully emerge through TDD. It leads, as Cope says, to overly procedural designs, and misses most of the benefits of object-orientation. For years I've read the debates over "when to introduce patterns" into a TDD process, with the consensus seeming to say "when you refactor". Except that some codebase mistakes (architectural ones, or core domain misunderstandings) are not refactorable -- they require overhauls that don't have the safety properties of the refactoring operations.
Again, from Cope's blog (emphases mine)...
If we're going to do testing, that's where the focus should lie. The interface is our link to the end user. Agile is about engaging that user; TDD, about engaging the code. TDD is a methodology. TDD is about tools and processes over people and interactions. Woops..... Sorting these things out requires a system view. It used to be called "systems engineering," but the New Age Agile movements consistently move away from such practices.
What's funny I see a lot of evidence that companies agree with this, even if they still get the development methods and funding models horribly wrong. The "architect" has been a rising profession, and while it is an abused term in many cases, sometimes an object of scorn, there is a desire for people that can see the whole.
From my view, TDD is a complement, not a replacement for
- Usability design & testing
- Domain knowledge
- Architectural constraints
- Stable intermediate forms & leverage at the interfaces (two classic systems heuristics)
- Design for performance
Simple framing question: Has a TDD-like emergent design process ever lead to a breakthrough product?
Leave a comment