Testing and Pseudo-productivity

I just finished watching Is TDD Dead? - a series of Google Hangouts recorded live on air about a month ago. Inspired by the RailsConf 2014 keynote and subsequent blog post by David Heinemeier Hansson, these conversations include DHH, Kent Beck, and Martin Fowler. After reading books written by all three participants* it was incredibly fascinating to learn more about their personalities and points of view in this format.

One point that is often revisited in the discussions is the concept of TDD as an addictive practice. DHH poses that the classic red/green/refactor workflow leads to regular releases of dopamine in the brain each time a developer writes a new passing test. He asserts that this practice takes too much emphasis away from the production system and leads to test-induced damage including but not limited to bad design, over-testing, and unnecessary layers of abstaction.

While this may be true in some extreme cases, the point that was left out of the discussion is that addictive bad practices are not limited to TDD. There are many ways to trick yourself into feeling like you are making progress when you are in fact not. Other forms of addictive pseudo-productivity include:

• Getting attached to your first solution
• Self-imposed scope creep
• Fancy Implementation Syndrome (FIS)
• Faster == better

Some developers get a similar shot of dopamine when they think of a solution which leads them to not consider better alternatives. Or when building a feature it may be tempting to add a bunch of unrelated "quick fixes" as a form of self-imposed scope creep. Fancy Implementation Syndrome (FIS) is a concept akin to Fancy Play Syndrome (FPS) in poker and involves using an overly "clever" design when a simpler solution is better.

And I have too often encountered developers who get a rush from building a feature or fixing a bug as fast as possible. Such developers like to proudly proclaim "I can write that in less then an hour!" Hasty solutions are especially dangerous in a system without proper test coverage as the collateral damage can cause countless hours of lost productivity in the long run due to tight coupling, unintended side effects, and decreased readability and maintainability of the system.

I won't claim that TDD is a one-size-fits-all prescription for solving every issue in software development. But the discipline that comes from the exercise of TDD can be an invaluable tool in minimizing bad practices that emerge in the absence of any sort of structured workflow.

References
Rework, Jason Fried and David Heinemeier Hansson
Test Driven Development: By Example, Kent Beck
Refactoring: Improving the Design of Existing Code, Martin Fowler et al.