And it hit me: we are not emergency designers.  We never have been.  We ask tough questions and spend time in discovery and research.  We dig and dig before we ever start designing.  We make recommendations.  We’re not “yes” people; we’re “why” people.  When you tell us your website needs a feature, we don’t just agree; we ask why. Then we push you (and ourselves) to dig up a better answer or provide a foundation to back up your request.

And yet, we end up “hurrying up” more often then I’d like.  We tend to take on emergency projects even though they don’t fit our general mold of process and project management.

It’s not that we can’t build a site quickly; we certainly can.  It’s more along the lines of our initial approach to a project.  Once we get to the design and development stage, we’ve already done our due diligence and the process can fly. But we like to know we got there with good reason and research.  We like to know the stakeholders are all on board with what we’re about to produce, and we like to know that every conversation that needs to be had has been had.

We’ve had a virtual onslaught of new project inquiries in the past few weeks.  And that’s a great thing, of course. We’ve been working hard on great projects and launched this gorgeously redesigned site and have been out writing, speaking and getting to know folks. Our clients give us fantastic referrals to everyone and anyone. We’re busy and loving it.

Of the new inquiries, a handful are really great, qualified, well-fitting projects for our team. Clients who want us to spend the time digging and learning and researching before we build; who want us to labor over the details and create really polished, beautiful web and mobile apps.  Who want us to thoroughly test the products before they launch.

And another handful are looking for “emergency” designers to take over a project that went south or start on something immediately that was supposed to be done last week (I need this 200 hour project launched by mid-February!).

Next time you have an emergency, open this box.

To these emergency clients, how fast we can get them a proposal reflects on how fast we can turn the project around – when in fact, the two are not at all related.  We need time to spend doing our research before creating a proposal. We need time to determine the best platform and approach and our own resource assignments.  It’s a complex matrix and it all takes time to do it well.

That said, we’ve taken on quite a few projects that weren’t going well and turned them around – but those clients recognized that the process would take both time and hard work.  They brought us realistic expectations and we turned out some awesome work.

It’s amazing when expectations meet reality, isn’t it?

I’m feeling liberated in this realization.  It’s yet another “red flag” for my arsenal of client selection tools that help us determine fit for new projects, and a step forward in solidifying our approach to design and development.

Do you find yourself providing emergency design services?  How to you react and how do those relationships turn out?

1. Document Your Code.

This is the most obvious item, and the one that nobody likes to do. It seems like a waste of time, but taking a few seconds to explicitly say what everything does will save everyone time and headaches in the long run. What seems intuitive now can take a few minutes to interpret down the road, depending on stylistic differences and familiarity with the system. Your documentation could save someone an hour or two of digging through code a few months down the line.

Being able to tell what something does, in plain english (or whatever your project’s common language), with only a glance, saves time and keeps frustration down. It’s just good business.

1.5. No, Seriously, Document Your Code.

Using TextMate? “doc[tab]” above a PHP function will add a DocBlock. There’s probably a similar shortcut for practically every IDE.

Releasing a framework or library to the public? Please, please provide docs. Even just in code. Nobody wants to dissect the whole system every time a simple task arises.

2. Use Descriptive Variable Names.

$product_discounts > $pDiscounts > $pd

It all gets compiled into a symbol table anyway. Use variable names that clearly describe their purpose and contents. This is the cheapest and most effective documentation you can do. Take a look at this:

// get the discounts for each product
foreach($product_list as $product_id) {
  $product_discounts[] = $discount_model->get_discounts_for($product_id);
}

While it may not be optimal, it still makes the point. Reads nicely, right? Now try this:

foreach($plist as $p) $pd[]=$dm->dFor($p);

Does it take less time to type? Sure.

Will it make your current and future co-developers very unhappy? Yup.

Don’t do it.

The same goes for function names. If you find yourself documenting a function with “Does what it says on the tin,” you’re doing it right (you should still document the parameter(s) and return value(s), of course).

3. Follow the Conventions of the System

This is a short one. If you’re working in an MVC environment, don’t put a few hundred lines of controller logic in the view. Don’t put model logic in the controller OR the view.

Generally if things are structured a certain way, keep them that way, unless you have a very convincing reason to do otherwise (and if you do, document it).

4. Refactor Repetitive Code

I once knew a professor who said (paraphrased) “If your function is longer than ten lines, you should split it up.” I’m not going to advocate that kind of strict line count rule, but at least follow this simple one:

If you find yourself cutting and pasting code, consider making it a function. The same goes for if a particular set of tasks can be described by a function.

Here’s an example:

$this->collection[] = $this->load->something(‘first’);
$this->collection[] = $this->load->something(‘second’);
$this->collection[] = $this->load->something(‘third’);
$this->collection[] = $this->load->something(‘fourth’);
// and so on…

Inline rewrite: 

foreach(array(‘first’,’second’,’third’,’fourth’) as $thing)
  $this->collection[] = $this->load->something($thing);

Function rewrite (generic):

// if you have access to $registry from this scope you don’t need it…
function load_things(&$registry, $thing_array) {
  foreach($thing_array as $thing)
    $registry->collection[] = $registry->load->something($thing);
}
 
load_things($this, array(‘first’,’second’,’third’,’fourth’));

Of course, if you have hundreds of items in there, you’d either have to type them all out or make some optimizations. Which leads me to…

5. Multiple Lines are OK!

Break up the following over multiple lines if your language allows it: Strings, arrays, SQL statements, and long function calls.

Take the following SQL for example: It’s pretty short now, but if there were a few more joins and constraints, it’d be a nightmare to maintain on one line.

// This is completely valid in PHP. Using {} interpolation is a personal preference.
$prefix = DB_PREFIX;
$sql = “SELECT * FROM {$prefix}things AS t
   LEFT JOIN {$prefix}other_things AS ot ON t.id = ot.id
   WHERE t.id = ‘{$this->db->escape($id)}’
   LIMIT 0, 100”;

In the case of long function calls, consider using an associative array (or dictionary) to pass in extra parameters. They have the added benefit of naming what they’re passing. Example:

do_something(“things”, 2, 455, 299, 200, 349); // no meaning without looking up docs

…versus…

do_something(“things”, array(
  ‘x_offset’ => 2,
  ‘y_offset’ => 455,
  ‘x_skew’ => 299,
  ‘y_skew’ => 200,
  ‘whatever’ => 349
)); // meaning is clear!

The more you can do to make things clear, the better. Nobody likes scrolling through a concatenated string 1000+ characters long on only one line.

6. Pick Common Conventions

Choose some well-thought-out conventions for your project(s) and have everyone stick to them. Even something as simple as standardizing tab widths and types will save some serious headaches. Take CodeIgniter’s style guide for example: Probably a bit overkill in some cases (OR versus ||, for example), but it has some great ideas, and it keeps things readable across the project.

You’re entering into a relationship that is going to last a very, very long time because seriously?  Moving websites from one server to another is a pain in the ass.  A serious headache.  Incompatible versions of PHP? Check.  Out of sync SVN repositories? Check.  Inability to render filetypes?  New IP requiring reissuance of SSL? Folders of uploaded assets not committed to the SVN repository?

Should I go on?

Everything we’ve encountered is a small problem unto itself;  together they form a huge headache and a couple days of troubleshooting.

So my warning is this:  a web host decision is a much bigger commitment than you might think.

• Do a little research and read reviews before you make that commitment.
• Find out how their customer service responds to issues.
• Is their default server setup compatible with the software you want to utilize (i.e. WordPress)?
• Does your web design team have any advice?

And if you take nothing else away from this warning, just stay away from GoDaddy hosting.  Please.