Challenging the Priesthood
It seems to have taken awhile, but people are finally speaking out strongly against the papal infallibility of the TDD high priesthood. Michał Bartyzel, Andrew Binstock, and Jim Coplien (who actually has been speaking out against it for years) are a few of these blasphemous heretics.
Any of the “driven” techniques can work, but to insinuate that they are the “only way(s)” to build superior products is arrogant, hubristic, and plain stupid. In mentally challenging, knowledge-intensive work, people have, and always will have, different ways of creating beautiful products.
When I speak with adherents of test-driven development (TDD) in particular, there is a seeming non-comprehension that truly excellent, reliable code was ever developed prior to the advent of this one practice. I sense their view that the long history of code that put man on the moon, ran phone switches, airline reservation systems, and electric grids was all the result of luck or unique talents, rather than a function of careful discipline and development rigor. – Andrew Binstock
“…these promises were not supported by unambiguous and verifiable data in early years of TDD. The enthusiastic reaction to TDD came first and then some (selective?) measurements were made to verify its promises. – Michał Bartyzel
“If you find your testers (or yourself) splitting up functions to support the testing process, you’re destroying your system architecture and code comprehension along with it. Test at a coarser level of granularity.” – Jim Coplien
Personally, I start sketching out quite a bit of a design upfront (OMG!!!!!) in “bent” UML (OMG, OMG!!!!!) prior to writing a single line of code. I then start writing the code and I subsequently write/run some selective unit tests on that code. In summary, I dynamically build/test the code base toward the coarse, “upfront” design as I go. Of course, according to the high priests of TDD, I’m unprofessional and I obviously produce inferior designs and bug-ridden, unmaintainable code. Gosh, it sux to be me.
For more details on how I develop software, check out this four year old post: PAYGO II. And no, I’m not promoting it as better than your personal process or, gasp, the unassailable holy grail of software development… TDD! No books, magazine articles, conference talks, or two-day certification courses are planned. It’s simply better for me, and perhaps only me.
Leave a Reply to bulldozer00 Cancel reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
Gosh I bet you are so unprofessional that you iterate that “up front” design as you go too? 😉
Shhhhhhh! That’s not supposed to get out. Now the Personal Practice Police Professionals (PPPP) will be bangin’ down my door again.
Today’s buzz is to come down on TDD. You seem to be just joining in. Do you have anything new to add to the argument? Can you suggest anything that works as well or better than TDD? If so,l speak up; I want to hear about it. Thanks.
It’s about time someone buzzed TDD’s prior unquestionable worth, don’t ya think? Don’t I say how I personally develop software at the bottom of the post? Isn’t that an alternative to TDD? Also check out my PAYGO posts: PAYGO and PAYGO II and fire away at them, dear friend. Oh, and why post the comment anonymously?
It seems that, as of, 9:05 the only question that separates the two is whether the architecture MUST be done up-front or whether it CAN be done incrementally.
Neither drives me one way or the other. I personally have seen architectures driven incrementally, an in radical directions, and so I have a slight agreement toward Bob’s point of view, though I have great respect for Cope, who has given me good advice (in books, tweets, forums, comments) and perspective through much of my career.
I’m undoubtedly indebted to both of these men for my software education.
I have nothing against TDD. If it works for you, then fine. My targets are the TDD elitists who “know” what’s best for all.
I am not supporting any particular idea. If there are methods that helped us develop phone switches, airline systems and electric grid then I want to read about them and adopt those ideas. TDD popularized an idea that is generally easy to use. Some simpler ideas tend to be powerful also. Older ideas may not be as accessible to the general community as TDD. I want to access them. How ?
I recommend reading (coding-independent and process-independent) design and architecture books like: Booch’s “Object-Oriented Analysis & Design With Applications”, the GoF “Design Patterns” book, the 5 volume POSA series, Bass/Clements “Software Architecture In Practice”, any Jerry Weinberg book, any Jim Coplien book, Fred Brook’s MMM & “The Design of Design”, M. Page-Jones “Fundamentals of OOD”, Gomaa’s “Designing SW Product Lines”, Bosch’s “Design and Use of SW Architectures”, any Bruce Powel-Douglass book, any Jack Gannsle book, any Steve McConnell book. Poke your head above the test-first, code-first mentality at least temporarily to see what the pre-TDD era people did to attack SW system design. Learn how to make abstraction your ally. Explore DDD (Design Driven Development), ADD (Architecture Driven Development) and MDA (Model Driven Architecture) approaches – even if you eventually end up back developing/building systems from the bottom up. Unlike TDD, there are no short-cuts or cookbook red-green-refactor mandates. Try getting a skeletal collection of collaborating classes that capture the essence of your “upfront” design up, connected, and minimally running before filling in and unit testing the details. Doing a bit of global scale designing upfront first doesn’t necessarily preclude using TDD at the local design level. Try building the skeleton, and then adding flesh. Let the design inform the code, and the code inform the design – iterate. Bounce around between architecture-design-coding-testing as you learn and let your intuition direct you where to go from moment to moment.
Cheers!
You quote Binstock: “I sense their view that the long history of code that put man on the moon, ran phone switches, airline reservation systems, and electric grids was all the result of luck or unique talents, rather than a function of careful discipline and development rigor.”
I don’t know about putting man on the moon (not a lot of software there anyway), but I worked on widely-used phone switches twenty years ago, and I will unequivocally state that when that software worked properly, it was indeed the result of luck and unique talents. Careful discipline and development rigor had nothing to do with it.
Gee, I wonder how many other people who worked on those projects would agree with you. I’ve worked on defense and traffic control radars for 20 years and careful discipline & rigor worked well there; way before the revered TDD.