On always seeking a better mousetrap

This is a response to Joseph Wilk’s thoughtful commentary on my previous blog post. However, in my desire to share it more broadly, I am including it here.

I thank you for your typically kind and reasonable tone; I have come to expect nothing less from you. And I thank you for indulging what, in retrospect, I am finding to be a horrid step out of character for me (or, at least, who I want to be).

To be very clear, I have found value in several of the ideas represented in Cucumber. And, for that matter, I am likely in your debt, in particular, for my realization of preference for outside-in development while at Scotland on Rails.

Now to your individual points:

Given that we exist in an open source world, I believe that we are remiss if we treat our tools as black boxes. Every open source tool is inherently a work-in-progress. To that extent, every user has an opportunity to attempt to contribute to the development of a tool. But, also, and perhaps more importantly, they have the opportunity to extend their tools to personalize them to their needs and, by extension, improve upon them in ways that may benefit others.

Put another way, for myself, I consider my ability to elaborate upon a tool to be a key part of its functionality.

However, from my discussions with folks at NYCamp this weekend, I was reminded that what is good for the goose is not always same for the gander. Cucumber is a perfectly fine tool for those who are still learning the “BDD way”[1]. Having focused upon TDD for the past several years now, my particular approach to it is such that I needed a tool that better supports my needs. I could write that tool or specialize another tool in such a fashion. I found Test::Unit to be a more comprehensible code base for that.

My point: my approach, as facilitated by Coulda, is not for everyone. Nor was my intent in my previous post to trumpet Coulda to the community.[2] Put another way: I wrote Coulda for myself. It suits my needs. However, my needs are not unique. In this, we are both clearly in agreement that a multiplicity of options is a good thing.

A great deal of the Java backlash has been due to the well-founded complaint that one need several bookshelfs of literature to write web/enterprise applications with it. When a tool’s API is such that it cannot be comfortably used on an ongoing basis without frequently referring to documentation, I believe that is a failure. I have commented on this to acquaintances with regard to Rails for some time. However, of late, I am finding that same complexity throughout more of the Ruby ecosystem.

The Pareto principle can be used here to imply that 20% of the work is necessary to create an 80% solution. Four times that much work and/or code is necessary to achieve the remaining 20% for a “complete” tool. This is an awful generalization but I make it solely to illustrate a point: tools that attempt to provide near-complete solutions to problems are all but guaranteed to be extremely complicated. And so we have several notorious tools in Java and, over time, in Ruby (or, really, whatever the language of the zeitgeist may be).

Perhaps I am cynical but I believe this dissolution into complexity is unavoidable. Entropy always wins. And then we try to start over again somewhere else. We can, perhaps, delay the inevitable. That is my modest hope in writing posts such as this.

While we may be knowledge workers, the “don’t make me think” attitude is still pervasive even in our industry. I am concerned that for something as important (or that you and I, at least, consider to be important) as TDD, that so many in the community blithely accept the tools given to them instead of attempting to improve upon those tools.

At times, I feel as though I am patronizing the community; however, truly, that is not my intent (however much my last post may appear otherwise). I want Rubyists to think. We should carefully measure the value of a tool before integrating it into our day-to-day lives. We should always consider the option of inventing a better wheel.

[1]: I consider BDD to be a superset or different perspective on TDD but, at the core, representing the same ideas. The emphasis, espoused by RSpec and Cucumber camps (as well as myself) being to focus on business value and precisely choosing the right words to capture the essence of the feature at hand.

[2]: In the past several months, I’ve left Coulda’s small code base grow in a less than managed fashion to the point where I don’t feel comfortable extending it! Acknowledging how this fails to meet my criteria for a functional tool, I am currently in the process of rewriting Coulda.

Posted by evan on Monday, February 07, 2011

blog comments powered by Disqus