How do you turn an unhappy client into a satisfied one? No matter how long you’ve been in business, you’ll eventually have a client who isn’t pleased. Highgroovers strive for constant client satisfaction, but we have tips for turning a frustrated client into a repeat one.

If you suspect a client is unhappy, communicate early and often.

None of us wants to admit it when our client is unhappy. There are a number of reasons for this:

• We hope that we’ll be able to fix the problem before anyone else finds out.
• We don’t want our co-workers to think less of us.
• We’re worried that we might get a poor performance review, get skipped on an upcoming raise or even get fired.

At Highgroove, we recommend communicating early and often. Talk to your co-workers; they are there to support you when things get tough. It can be difficult to let your guard down and ask for help, but you will be relieved to realize that you don’t have to go it alone. Together, you can work as a team to restore client happiness.

We also recommend increasing communication with the unhappy client. When we’re faced with an unpleasant situation we might:

• Find ourselves hesistating to respond to phone calls or emails.
• Imagine that the issue will be forgotten or resolve itself on its own.
• Become overly focused on finding a solution at the expense of communication.

It’s better to address the unhappy client early and directly. Slow or nonexistent communication can cause your client to panic–not only do they have a problem, but now they have no one to fix it! Always reply quickly, letting your customer know that you’re aware of the issue and moving towards a solution. Then keep them updated on your progress.

Resist the urge to go overboard on attempts to restore happiness.

When a client is unhappy, we often want to go to great lengths to improve the situation. You might be tempted to pull developers from another project and add them to the distressed one. Or you might ask developers to work late into the night and over the weekend in an attempt to catch up. You may find yourself no longer following your best practices as you try to recover lost ground.

We recommend sticking to your established process, especially when the going gets tough! Otherwise, you might go too far to satisfy a client’s request to speed things up. Would you pull your entire team and put them on the distressed project? Would you ask your developers to work 16 hours a day? Would you skip source control and edit code directly on the production server?

Going overboard is actually likely to slow things down and make your client even more unhappy, rather than improving the situation. It may be easiest to say yes when an unhappy client asks for more developers, longer hours or shortcuts, but taking the easiest way isn’t the best way. As Fred Brooks pointed out in The Mythical Man- Month, “adding manpower to a late software project makes it later.”

Instead, we recommend attempting to explain these counter-inituitive truths of software development. Give your client the opportunity to understand that you are acting in their best interest by sticking to your established process.

Have you ever had an unhappy client? How did you respond?

Image credit: photocapy

The post An Unhappy Client appeared first on Big Nerd Ranch.

I’ve often felt like Ruby Regexp captures are a bit clumsy.

Let’s say we need to break apart phone numbers:

After executing this match, we might do something like this with the parsed number:

What’s up with the dollar signs and the sequential numbers?

I feel like I’m writing assembly code and referring to registers or memory offsets or something.

If I’m a new Ruby programmer reading this code, I might have no idea what is going on here.

We can do better if we upgrade from magical variables to the Regexp.last_match method:

At least this is a bit more readable than the magic variables.

And it’s probably easier for a newcomer to find documentation for Regexp.last_match than $1.

But there’s an even better way in Ruby 1.9 – named captures:

Now we’ve got readable code, and better documentation built into our regular expression.

Are you using Ruby 1.9 yet? If so, have you had a chance to use named captures?

The post Refactoring Regular Expressions with Ruby 1.9 Named Captures appeared first on Big Nerd Ranch.

Here at Highgroove we like a good challenge, and we love it when we can meet a challenge with a simple and elegant solution.

Recently we had a customer with a great problem to have – they had signed up lots of new customers and were experiencing some growing pains.

A typical Ruby on Rails app has one database. This app had one database per customer.

Routine tasks like launching servers, deploying code, or migrating databases were taking much longer than normal because they had to be performed per customer instead of just once.

What this app needed instead was Multitenancy – a fancy word for combining the customers into one database.

To combine safely, we’d need to ensure each customer’s unique keys no longer were in conflict with each other.

Here is an example of unique keys before the merge:

Customer A     Customer B

1

Bob

1

Frank

2

Alice

2

Eleanor

And after the merge:

Customer A & B

1

Bob

1

Frank

2

Alice

2

Eleanor

You can see the unique keys are no longer unique.

How do we fix this? Time to look at some code:

This bit of code will give us the maximum id across all tables in all customer databases.

Once we know the maximum id, we can reassign each customer’s unique keys with enough offset to ensure there are no conflicts:

This will give us the combined table:

Customer A & B

3

Bob

customer_a

4

Alice

customer_a

5

Frank

customer_b

6

Eleanor

customer_b

Now we’re off to the races – with a single database containing records for all of our customers – and no unique key conflicts!

Have you ever had to combine conflicting database records? How did you tackle the problem?

The post Combining Many Customer Databases into One appeared first on Big Nerd Ranch.

Here at Highgroove we often use the popular Factory Girl gem in our tests.

I also like to use a data generation library like Forgery in combination with Factory Girl.

Forgery allows me to improve my factories by using realistic instead of contrived data.

For example, here is a User factory without Forgery:

And here is the same factory with Forgery:

Now, each user created by the factory gets a realistic email address.

This becomes useful if you include Factory Girl and Forgery in the development group, in addition to the test group, in your Gemfile:

Now your factories are available from the Rails console in development mode.

Let’s say you want to spin up some records in your local development database so you can see a view fully populated with realistic data. From the console simply do:

Now you’ve got great looking data on screen for a demo, screencast, or perhaps some debugging.

What do you think? Is realistic data in your factories important to you?

The post Factories with Realistic Data appeared first on Big Nerd Ranch.

As an index investor, I was fascinated when Y Combinator launched their innovative style of startup investing.

Y Combinator spreads their portfolio over a large number of startups, similar to the way an index fund spreads its portfolio over a large number of holdings.

Furthermore, with smaller funding amounts at risk, Y Combinator can provide guidance with a light touch from afar without micro-managing. Similarly, index investors do not concern themselves with the minute details of the companies held in an index fund.

At Highgroove, our customers are often early stage startups, who sometimes offer us an opportunity to take equity. Like an index fund, we can diversify amongst this pool of customers, while keeping the investment amounts small to avoid needing to materially participate in any customer’s core business. (We prefer to stay focused on our core business – software development!)

Many software developers working for a consultancy might be wondering if they are missing out by not taking equity at a startup.

When Highroove takes equity in a early stage startup customer, that equity is shared amongst the Highgroove employees. The result is that our employees own a diversified portfolio of equity in many early stage startups!

What do you think are the pros and cons of this setup? Does your consultancy offer this or a similar program?

The post Taking Equity appeared first on Big Nerd Ranch.

At Highgroove, we value customer service along with programming. Our customers arrive at our shop with concerns needing attention. Here are a few common ones:

• They are new to software development

• They have a fixed budget

• They have a defined time frame

• They need help on an existing project which is in trouble

• They need assurance we will be available after the project is complete

It helps us to imagine questions our customer might have:

• Am I choosing the right team to bring my project to life?

• Will my budget be spent wisely?

• Will my project be done on time?

• Can these consultants succeed where others have not?

• Who will I call when I find a bug, or need a new feature?

Staying mindful of our customers allows us to deliver better service. Here are some techniques we recommend:

• Use your customer’s terminology. It might feel good to ramble on in code-speak in front of a customer, but resist the urge or stop yourself short if you catch yourself doing this. Customers who are new to software development are better served if you stick to the terminology of their domain, rather than indulging in yours.

• Always deliver working software. Customers on a fixed budget are stranded if you’re halfway done with bunch of features but you’ve blown the budget. Break features down into small stories which can be accurately estimated. Then, commit and deploy these completed stories early and often, steadily delivering value.

• Be brutally honest when estimating time. This is personally a tough one for me. Resist the urge to be an overly optimistic Superman. Customers take your word when you give estimates. Make sure that your features will be ready for the demo they’ve scheduled.

• Know when to say no. Many projects are in trouble because they’re lacking constraint. Customers with a troubled project are likely in need of a fresh set of eyes to trim the fat and ship a working product, rather than a perfect one.

• Establish a relationship. Some consultants are passionate about programming at the expense of customer service. They can be overly defensive when times get rough, even abandoning projects and burning bridges. Customers are best served by consultants who keep a cool head and guide a project to completion. When a project is complete, the bumps in the road become memories, and a satisfied customer provides new projects and enthusiastic referrals.

What techniques do you use to deliver better service to your customers?

The post Customer Service for Consultants appeared first on Big Nerd Ranch.