Chicken Makhani

Ingredients for stage one

• 1/4 cup vegetable oil
  
• 2 onions
  
• 1/2 cup chopped garlic
  
• 2 cups tomato sauce (not Heinz...the liquidy stuff in tins)
  
• 1 cup plain yoghurt (don't use low fat or fat free...it'll all go horribly wrong)
  
• 2 tbsp cumin/coriander (i.e. 1 tbsp each)
  
• 1/2 tsp garam masala
  
• 4 cloves
  
• 1 cinnamon stick
  
• 1" root ginger, peeled and chopped
  
• 3 bay leaves
  
• 2 cardomom pods
  

Ingredients for stage two

• 1 pint heavy cream
  
• 1/2 stick butter
  
• 1 tsp paprika
  
• 1/2 tsp ground black pepper
  
• 1.5 tsp salt
  
• 1/2 tsp hot chili powder

You will also need about 6 - 8 chicken breasts cut into bite size pieces.

Puree the onions, garlic and ginger in a blender. If you have a way to grind up the cinnamon stick and cloves do so. If not they can go in whole.

Heat oil till hot but not smoking, add cardomom and bay leaves. If you are not grinding up the cinnamon stick and cloves add them now. Stir for a few seconds then add the pureed mixture. Cook for 10 - 20 minutes stirring regularly to prevent it catching and burning. Add everything else from the stage one ingredients list and bring to a boil. The yoghurt may appear to curdle, but if it does don't worry -- everything will right itself shortly.

Now add stage two ingredients and return to a boil. Add the chicken pieces and simmer for 20 minutes or so until chicken is cooked and the sauce has taken on a slightly thicker consistency.

Serve with basmati rice and naan bread.

Naan Bread

• 1/2 cup plain yoghurt
  
• 1/2 cup milk
  
• 1/2 tsp baking powder
  
• 1 tsp white sugar
  
• 2 tsp dry yeast
  
• 1/2 tsp salt
  
• 1 tsp nigella (aka black onion seeds) 
  
• 2 tbsp melted butter
  
• 2 eggs, lightly beaten
  
• 3 cups plain flour
  

I've noticed that Indian restaurants in the US don't seem to put nigella in their naan bread whereas those in the UK do. Having spent most of my life in England I find them to be essential. I've made naan in the past without them though and they are OK, just missing that unique nigella flavor. In my opinion they are well worth seeking out. I found my last batch in an Indian grocery store. It used to be that Whole Foods sold them but last time I looked they have greatly reduced the variety of spices they now have. 

Start off by placing the yoghurt and milk in a large glass bowl and heating for approximately a minute or so in the microwave. Warming this up helps activate the yeast allegedly...

Next add the baking powder, sugar, melted butter, eggs and yeast to the bowl and stir well with balloon whisk to incorporate everything. Finally add the nigella seeds and stir to distribute.

Switch from the whisk to a wooden spoon and begin adding the flour. Add about a cup at a time and the stir in. When you have added all three cups if the dough is still too sticky add up to an extra half cup to make it easier to manage.

Turn out the dough and kneed for several minutes until it starts to have that nice sheen and elasticity that well kneeded dough has. Roll into a ball and cover with the glass bowl. Leave to rise for about an hour at room temperature. Dough should approximately double in size.

Once dough has risen divide it into at least four and as many eight pieces (depends how many you have to feed, how big you like your naan...)

Take each piece of dough and "encourage" it into the typical naan shape. This is a very approximate thing (for me at least) achieved through stretching, pressing and other general forms of manipulation as needed to get something reasonable looking.  In general the dough should end up pretty thin, a millimeter or two. No idea what fraction of an inch that is but not much...

Melt some more butter (perhaps 2 Tbsp or so) and brush each of your naan lightly on the top side.  Now place them butter-side down in a large hot skillet/frying pan that you have pre-heated and quickly brush the second side with a little butter. It should only take a couple of minutes before you need to flip the naan over. Use a fish slice to check on progress and ultimately turn the bread.

As each naan is finished transfer to a warm plate and keep covered with something (clean tea towel, foil, etc.)

These are great with any curry, but especially those with a lot of sauce.

Why we refactor code

Formulating an explanation in plain English for the non-technical

Late last week I received some “intelligence” that during a product meeting, one of our senior stakeholders exclaimed something along the lines of

“Why haven’t we made more progress on new features? Why have we spent all this time on refactoring? I don’t care about refactoring, it’s just fluff and no use to me.”

Unfortunately I missed this meeting. Or maybe it was fortunate. I don’t know that I’ve ever had to articulate to a non-technical person the purpose and benefits of refactoring code, and may not have done a great job if I’d tried to ad-lib. So over the weekend I mulled it over a bit, looking for a way to explain it that would resonate with someone like this.

The explanation had to be quick to explain and make patently clear the need for, and benefits of, refactoring. That itself got me thinking more deeply than ever before about why we refactor. Below is what I came up with. It’s all expressed in the context of the particular product that gave rise to this challenge, but I think the argument holds up across the board.

Here’s my basic premise: building software is like a game of Jenga™, and if you don’t do an appropriate amount of refactoring over its life the game will end sooner rather than later and everything will come crashing down. If that sounds odd, bear with me and I’ll explain. Let’s start with some background on the product that had given rise to the question:

• The product is a framework from which we build dozens of in-house web applications. They are all basically CRUD applications which vary a little from the functionality of the main framework (additional fields for example).
• The framework has had 7 releases over 5 years
• The first release had just over 1100 classes, the latest release has nearly 1800. That’s a 60% increase.
• Over its lifetime, at least 18 different developers in three different offices in two different countries have worked on it. There’s never been more than five people working on it concurrently so that’s a fair amount of staffing changes.
• The applications we build from this framework have the expectation that they can upgrade (or migrate as we call it) to newer releases of the framework than that which they were built upon

Now let’s build (no pun intended) the Jenga analogy. Consider each block in the stack is some piece of code, a class perhaps. Now obviously classes are more complex than this – they vary in size and have more complex dependencies, but as a simple model this will work.

Now, each release of the framework involves coding. That often means changing an existing class: pull out a block, "tweak" it, and then of course stack it on top. This represents how modifying existing code can lead to a more fragile situation. Unlike regular Jenga where you just use the existing blocks in the tower, coding involves adding new blocks. So your tower gets bigger over time, potentially making it a little more wobbly too. The other notable difference to help complete the analogy would be that whereas Jenga is played with 54 blocks, my framework here started with over 1100. And of course aggressive deadlines mean one doesn’t always have enough time to carefully consider how to position those blocks to best effect, but that’s how it goes...

After a few releases, our tower is looking pretty wobbly, although it still “works” just fine to the casual observer. After all, it’s still standing.

Business users: “We need you to add this new stuff.”

Engineers: “But those blocks are a completely different shape. Some of them are really oversized, and heavy. Besides, have you seen the foundations?”

Business users: “Yeah but if you could just tack them on somehow, that’d be great.”

See the problem is that the blocks are all rather precarious now. And some of them we never wrote ourselves we just use them. But they’re old, unsupported and clunky. We need to replace them or update them. We need to shore up the foundations. We’ve also noticed in the last five years that the business uses them in ways we didn’t appreciate when we first assembled them.

We need to reorganize the blocks a bit. We need to get rid of some of them, we need to simplify them. We need to shore up the foundations. We need to make some new blocks too, better suited to the way we have learned they actually get used. Considering how much we use them that’ll save money. In short, we need to refactor.