Critical Path Newsletter

Development nightmares: Steps for effective behavior change

I’ve discovered a new favorite TV show, Kitchen Nightmares. In it, real-life chef Gordon Ramsay, one of the most successful restaurateurs in the world, goes to struggling restaurants and troubleshoots their problems.

I had an epiphany during an episode a few weeks ago, while Chef Ramsay revisited the restaurants he helped last year. I realized that no one sets out to open a restaurant that serves bad food, that they will be ashamed of, and that will lose a lot of money for them.

No one does that on purpose—they arrive at that destination through a series of small, desperate compromises. If you don’t have many people coming into your restaurant, buying frozen vegetables instead of fresh makes perfect sense, financially. If you hire too many waiters and you like all of them personally, which one do you sacrifice for the sake of the business? After all, you’re losing money anyway. It’s less painful just to keep them on.

Over time, these behaviors become habits that drag the owners/servers/chefs down and they can’t even see the problems on their own.

It’s the same with us in software.

We all have our development or management habits and attitudes that we’ve developed over the course of our careers. Some good, some not so good.

Why do we have those habits that we know aren’t so good? Cutting corners, doing things by rote… They aren’t habits we’ve accidentally slipped into and accidentally repeat on a daily basis. We do them because they give us some reward.

‘Lazy’ habits are usually a source of efficiency, either in time or in effort. For example, a developer who adds code to silently swallow an error condition saves time in the short term, maybe during a sprint where he otherwise wouldn’t have made his goals. Plus, he frees up headspace that he can use to think about another cool feature.

Maybe he even intended to go back and add the missing exception handling code. But then that next tight sprint came along and that task got shoved further back on the plate.

Generally, smart people don’t make lazy choices. They make efficient compromises as a reasonable short term solution. They see the quickest answer to a problem pressing on them right now and take it.

Unfortunately, in the long run, efficient compromises turn into lazy habits. It’s worse when that developer moves up the food chain and trains other people.

But making people change their bad habits can be one of the most difficult things a manager has to do. You can’t just order them to change because as soon as you stop watching, they will go back to the way that has always worked for them.

As I kept watching Kitchen Nightmares, I realized that one of the things that makes Chef Ramsay so watchable is his ability to make people want to change. To get the restaurateurs to want to get rid of bad habits, he often goes through three things with them:

• Examines what they are doing now
  
• Revisits how they got this way
  
• Gets them to imagine what the future will be like if they keep doing what they’re doing
  

And it’s the same for changing our own problem habits—or those of our team members. Let’s have a look at how this could work.

What they are doing now
On Kitchen Nightmares, this usually takes place when Chef Ramsay eats the food and looks around the restaurant. He asks questions like “Is this crab fresh or frozen?” “Is this supposed to be lamb or beef?” and in the worst case scenario, “Is there meat in this vegetarian entrée?”

In a development situation, this would probably take place when someone else works on the code. Having another developer  try to implement a new feature or fix a bug can identify blatant issues turning into bad habits.

How they got this way
On Kitchen Nightmares, the chefs have often lost their passion for cooking for a reason. You can’t blame someone for deep-frying a rack of lamb if the oven and stove don’t work. Sometimes dishes need to be cut from the menu so that the chef can focus on doing one thing really well.

Why is the code full of hacks or incomplete features? Is there a valid reason for it? Is the manager assigning too many tasks or expecting too much work in each sprint? Is there a problem with the server or the development environment?