Eric Torrey

Test driven development has come a long way, but in honesty it’s not easily inspired.  I spent a long time cleaning up my co-workers code and replacing complex logic with explicit tests.

The idea and concept is easy to fake.  The problem is, tests will prove lies.  It’s easier to just call something ‘done’ then it is to finish it.  When you’re being overworked, the concept of ‘finishing’ something is a joke.

Companies that value a quick bug fix over software that works are wasting your time.

Legacy Code Stink

Applications go through various stages of development.  The shining moments for an application are usually in the early stages.  There isn’t much complexity, there is plenty of time left until ‘launch day’, and developers are usually relaxed when coding.  Eventually every application suffers from poor feature requests, bad design, and rushed code.  The beautiful grassy plain of peace your application used to be is turned into a bustling city.

Boston is a city in Massachusetts that was founded a whole buncha years ago.  Back in the day, the guys pushing wagons around, and mules laden with baggage didn’t care about paths that they plodded into the ground.  All they cared about was getting their goods to where ever they needed to be.  If there was a ginormous rock in the way, they could just path around it.  After a while, cars started getting pretty cool.  Cars need roads, so all the roads were built right on top of those paths.

At that time, it was easier to just build a road on top of the path.  No one knew the windy mess of wagon-path converted roads would cause tons of lost tourists and traffic accidents today.  It might have been better to just nuke the ginormous rock out of the way, and make the road straight.  Unfortunately, that ginormous rock is some type of historical monument now, so it’s not possible anymore.

Anything is possible in software (with limit to it’s own scope), the only constraint is time.  Time is the key element here, it’s something you can’t get back.  Every decision that is made in software has an effect on how long something else will take.  Every second saved by hacking around something today, is going to cost you two seconds tomorrow.

“Tomorrow is so far away though, and I need this to work now.”  When the pressure is on, and time is short, this is a common approach to decision making.  It’s in these essential minutes during an applications life span, that hacks start to leak into every crevice.  To make things worse, instead of refactoring the hacks out, time is spent building more new features.  Eventually those crevices become a major fault line, and it causes changes to the code base to take three times as long.  By this time, new developers have no chance of contributing, and the existing developers hate working on the application because everything they do causes an earthquake.

A major problem with software development is the existing solution.

Things change, standards form, upgrades happen.  The best idea you ever had yesterday, can probably be done better today.  Don’t let your legacy code stink take over, get rid of it, refactor it, and upgrade it.  There is always a better way to approach a problem in software and in most every case the quickest solution is the worst solution.

( Originally posted on AgoraGames: http://blog.agoragames.com/2008/11/03/legacy-code-stink/ )

It’s official

Disambiguate rails helpers

(originally posted on giantrobots at thoughtbot.) 

Here at thoughtbot we strive to make explicit, agile code. We know the specification changes, it’s what we’re machined for. The place that changes the most, and is usually the hardest to maintain are the views. As my comrade pointed out the views usually run wild, so we use helper methods to prevent a long method chain, and keep things a little more readable. Sometimes however that usually leads to methods that aren’t used, or methods that are duplicated.

For example. Let’s assume you have a Blog, that belongs to a User, and has many Posts. Pretty standard right? There is no requirement for the Blog to have it’s own title so instead we use a helper method. On blogs#show we use a Blog helper method defined here:

module BlogsHelper

  def display_title_for(blog)
    "#{blog.user.name} - The Blog!"
  end

end

Good, now when a user clicks on a Post for that Blog, we get to posts#show. At the top of the page, we want to display the title of the Blog. So we try to call #display_title_for and get a NameError, something along the lines of undefined local variable or method.

We can’t use the method in the BlogsHelper from the Post’s views yet. We could go into the Post’s controller and add this:

class PostsController 
  helper :blogs

  def show
    @post = Post.find params[:id]
  end

end

I don’t like this solution, sure your being DRY, but your not being explicit. What happens when someone wants to change the display of the Blog’s title, and they are looking at the posts#show view? They will immediately look for a display_title_for(blog) in the Post’s helper – too bad it’s not there.

Another solution would be to duplicate the method on the PostsHelper. Although this also is a poor solution, if someone wants to change the way the blog title is being displayed, it will need to be changed in two spots.

So, I want helpers to be called explicitly, and defined explicitly. I want to know what is being called, and where it’s being called from. Let’s redefine the display_title_for(blog) on the BlogsHelper:

module BlogsHelper

  def self.display_title_for(blog)
    "#{blog.user.name} - The Blog!"
  end

end

Now that we have defined it as a module method we can use it in the post#show view like so.

  BlogsHelper.display_title_for(@post.blog)

Now we have explicit, dry, maintainable code.