---
title: 'Unpopular Developer 1: Come on in, The Water''s Fine'
teaser: Refactor code to make it elegant.
tags: web,rails
author: Floyd Wright
published_on: 2007-01-23
---

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 [<abbr title="Don't
Repeat Yourself">DRY</abbr>][dry-wiki].

[dry-wiki]: https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

<abbr title="Don't Repeat Yourself">DRY</abbr> 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':

[DHMO panic]: http://www.dhmo.org/facts.html

```erb
<% 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 <abbr title="HyperText Markup
Language">HTML</abbr> 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&#8212;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 <abbr title="Don't Repeat Yourself">DRY</abbr> 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.