Hi, I’m Floyd. This is my first post on Giant Robots, but I’m going to try and avoid a lot of fanfare and instead get right to the smashing. This is the first in a hopefully long-lived series of posts on unpopular development practices. That is, an analysis of how dogmatic application of so called ‘best practices’ are not always. Arguably this blog always has a long and glorious history in this subject, but I’m going to formalize it for ultimate satisfaction. The subject of today’s post will be the oft-hailed devotion to DRY.
DRY is a difficult concept to approach with second-guessing intentions. After all, it’s a catchy slogan with a simple easily communicated point, and to top it all off, a damn fine acronym to aid memory, or maybe…to prevent beneficial forgetting. And even worse, it’s kind of right. I mean, who hasn’t witnessed the glory of 20 lines of eRB reduced to two elegant lines in a helper.rb, or whole view files disappearing into the same template’s loving embrace? The Rails community has taken this so far that I fear a DHMO panic. But I believe it was Nietzsche who best made the point that true strength follows from the ability to forget unnecessary and especially mundane trivialities of everyday virtues in favor of bold creativity and daring. But before we scare anyone away with philosobabble, let’s see if this assertion is borne out by some fake code, which is nevertheless not at all ‘made up’:
<% variable = "long complicated string constructor
#{with.lots_of?(tertiary) ? conditions : "that account for every possible
case #{nested? "!" : "D:"}" }"
%>
<% with_multiple_variables = "and are impossible to read " +
with_methods(and) + variables " everywhere"
%>
<buried in="html">
<%= render :partial => one_of_thousands_of_helpers , variable + variable %>
</buried>
<% if x %>
<%= render :partial => a %>
<% elsif y %>
<%= render :partial => b %>
Hopefully, you’re revolted right now. Possibly even suffering from dehydration from excessive regurgitation of recently ingested vittles. The metaphor is apt, because this code is desiccated.
It doesn’t take a genius to know that 2 lines of HTML in 9 lines of eRB is just…sad. But it does take guts to admit that the specific insidious problem slowly killing the maintainer of this application is DRYness. First, take a look at those conditionals. Hoo-boy this template is conditional. That’s because it’s accounting for the 5-6 theoretical cases in which this view is rendered and drawing on tertiaries, blocks, and partials to stuff it all in the same potato bag. You may complain that this is a contrived example, but let’s be honest—it’s not. Have you seen the devil? I have, and he is dry. He bought the maintainer of this code’s soul for the price of the developer’s self-satisfaction, and a real nice slogan thrown right in.
Maybe it was wrong-headed for me to start out this article with a quotation from Nietzsche, because this problem might really be one of too much daring, too much boldness, too much cleverness. You can’t outwit reality, and the reality of keeping that code bug free has you by your sadly dusty cajónes, amigo. What do you do when client requirements change? Sure dry code is less code to change, but it’s usually also proportionately less reusable. Instead of changing more than one file, you’re faced with throwing out the one file you have and starting over, embarking on another of your fool’s errands of optimizing for another temporary requirement. Similarly, what happens when a bug surfaces in this morass? Instead of one clear logic to investigate, you’ve got multiple intersecting cases any (or all!) of which could contain the error being thrown in one of your views…
The lessons of DRY shall not be forgot. Refactoring code to be more elegant and more efficient is in many ways the hallmarks of good software development. But that is only the first step. First, this kind of egregious pre-optimization is not elegant anyway. Secondly, unless this is being hosted on of your grandma’s Compaq, the computer doesn’t care if your views are 4K or 4M. But if you have created software that doesn’t last, and isn’t fun to maintain as well as develop, you’ve lost the title, you’re entering the 8th Circle. You’re a dry little maple leaf, just waiting to be crunched to dust by the first passing boot.
