Every Monday morning our team engages in a sprint planning meeting.  Starting with a retrospective of the prior week, we discuss problems, successes, and ideas from individually posted notes on each topic  Intended to be frank discussions, we are openly enthusiastic about the good things that occur, but our challenges and frustrations are generally veiled.  The goals of a retrospective aim to improve the team’s flow, but if we aren’t honest about the challenges we’re facing, they are simply a waste of time.

During a retrospective six weeks ago, my Post-it note read:  “We are a dysfunctional team.”

For a couple of weeks, I felt frustrated and unhappy with the office atmosphere.  No one was complaining, work was getting completed, and there was no list of dissatisfying issues.  But there was a palpable sense of unhappiness among the team.  My posted note opened a long closed Pandora’s box, and so began our first real steps to re-creating the team.

We are not alone.

At SXSW, no less than four panels tossed around the subject of developer/staff relationships.  The consistency of the theme was surprising.  Two questions begged answers:  what factors lend themselves to these difficult relationships, and how do we change team dynamics?  I was on a quest to find answers and work on fixing our own team.

To start, we discussed what we collectively felt were the primary requirements of a <i>functional</i> team: trust, honesty, partnership, and commitment.  We were failing at all of them, and the negative pall cast on the office was tangible.

Each month, we’ll share the changes made and the results realized as we attempt to overcome the obstacles that prevent us from realizing our potential

As a developer, it’s easy to get buried in code and forget how people actually use what I’m writing.  An interface element or workflow that seems intuitive to me can often lead to confusion and frustration in the casual visitor.  If I want to transform my code into an application, I must become the visitor and walk the path I’ve built.  Each step must answer one question: Am I showing something useful?

Answering this question is a powerful way of evaluating any design.  Too often, it’s easier to display some sort of bland, generic page that does nothing of value.  Each of these non-pages cost us visitors who would rather spend time doing something useful instead of aimlessly wandering, looking for the next step.  All the visual gimmicks and traffic-generating tricks in the world are for naught if I can’t say “Yes, I am showing something useful.”

On one of our projects we were porting over a legacy application written in PHP to Rails. A lot of the application’s users accessed the site with bookmarked pages. So we wanted to redirect users when we saw specific words like “buy” or “.php”, so customers were not left staring at a 404 page.

To accomplish this we simply added a “catch-all” route in Rails. This allowed us to inspect the path and take action based on some kind of business logic. Below is the code added to the end of the routes.rb file:

map.connect ‘*path’, :controller => ‘redirect’, :action => ‘index’

This will redirect any requests that are not matched in the routes files to the redirect controller’s index action. In that method we can then define logic on how we want to handle the request. We can even perform actions with the database, since we’re inside a controller at this stage. In our case we simply used a regular expression to evaluate the URI:

def index if request.request_uri =~ /buy|.php/ redirect_to “/” else render :file => “#{RAILS_ROOT}/public/404.html”, :status => 404 end end

It’s a simple, yet powerful little technique for handling URLs dynamically.