The refactoring chef

25 Feb 2011

Can we go faster?

I don't remember when or where I first heard this analogy, but I've always thought it's an interesting way to describe what developers do. If I decided to share my version of it, it's because there is one discussion that seems to pop up so frequently, yet never settles: does refactoring slow us down? Could we do without it for a while to burn more points?

Warning: please note the following post is devoid of any "steak holder" jokes. And it wasn't easy!

A refactoring metaphor

So picture a small restaurant you like in town: the owner, running the place, and the chef in the kitchen. If you've ever witness a chef at work - yes that includes watching Masterchef - you will have noticed recurring actions throughout the preparation of a dish. Take, use, put away, tidy up. Usually in that order.

Regardless of how busy the restaurant is, you'll see the chef sharpening his best knife occasionally. If he didn't, the roast would take longer to prepare and I can guarantee a sloppy cut. If he didn't put the spice containers back on the rack when he's done with them, he would risk having to run around looking for coriander next time. But does he consciously think about these things? I don't think he does. That was part of his training, and it's now an intrinsic part of his job. He just wouldn't be a very good chef if he left a mess on the bench and let his utensils deteriorate.

Or course, the owner knows this. He doesn't ask the chef to skip drying the cutting board to deliver more steaks - he might not know how much of a bacterial hazard moisture is on a cutting board, he simply trusts his chef to do the right thing. However, trust is a delicate matter: scrubbing the bench spotless after each pan fried prawn would be counter-productive, and no owner or client would think 90 minutes is appropriate for making a prawn salad. That's why a good chef uses his judgement to find the right balance between cooking and keeping things tidy and working. On a bigger scale, if he realises the kitchen layout doesn't allow him to be fully efficient, he can't tell the customer his steak will take 2 extra days because of kitchen work. In fact, very much like a software team, a restaurant operates under continuous delivery. Anything hindering this requires a decision that the chef can help the owner make.

This is why I believe in the importance of mutual trust in the kitchen as in the office. Chefs, developers, be sensible in your daily judgement of what's reasonable tidiness, and keep your tools reasonably sharp - it's all part of what you do and no one should make you justify doing so. At the same time, be transparent about bigger changes you want to make, it's your job to convince your boss of the long term benefits of closing down for 2 days. Don't surprise your restaurant owner on a Saturday with a kitchen under repair. And finally, business owners, managers, please don't ask your team to leave the butter out on the bench for the sake of speed. We'd be pretty bad professionals if we said yes.

Comments