Rob and I took a coffee break from refactoring some code yesterday and he asked me if I had watched Ramsay’s Kitchen Nightmares the night before, which I had! We commented on how formulaic the show is – each episode Ramsay turns up at the door of an ailing restaurant, and helps get them back on track and making money by empowering and motivating the cooks, using fresh ingredients, coming up with a simple less complicated menu, keeping management out of the kitchen and in the front where they belong, and above all putting the customer first!! Rob then said something along the lines of “You know when you think about it its not too different to the problems that many other software engineering firms face“. That’s when the penny dropped …

As a metaphor this should sound familiar to anyone working on a large ( even not so large ) software project. Your coders are the equivalent of your kitchen brigade, guys and girls who have to deliver, without them you cant serve anything to your customers. Your ingredients are API’s, frameworks, and technologies. Your complicated menu’s are over analysed, over designed, and over complicated software architectures; and lets not forget your restaurant managers are the same as your project managers, who generally know sod all about writing code, they promise your customers everything under the sun, generally work their brigade to death to deliver to unrealistic time frames and have a penchant for blaming the coders when it all goes tits up!

Worst of all the customer rarely gets what he or she actually ordered, because so many software company’s still persist on following dated project management and development methodologies trying to gather requirements up front, do exhaustive analysis and design then coding, and finally delivering a system 12 months later to a customer who’s requirements have now changed.

Did I sound bitter then? It’s probably because I realise that I’ve spent the better part of a decade working for the kinds of software companies where this kind of thing is considered the norm. Sadly for many company’s it still is the norm!

So lets apply the Ramsay formula to this. How do you turn teams that are building software in the manner above around?

Firstly, you have to empower your brigade. In the past I’ve worked in places where the job of most developers is simply to “fill-in-the-blanks”… in other words just implement method stubs that are generated by a design tool that the architects use. This creates hierarchical divisions within teams, and is generally extremely de-motivating. Like a cook who has given up using his imagination, has no passion, and has given up thinking creatively and has been reduced to doing little more than reheating pre-cooked frozen hash.

In order to empower the team, they need to OWN the code collectively. It doesn’t belong to one person, it belongs to everyone. As a team they’re passionate about it. You have to be break people out of the traditional thinking that I wrote this class so people have to check with me if they want to change it!

We need “fresh” ingredients. Yes we should re-use software but only if its appropriate. How many times have you worked on software projects where the architecture isn’t based on whether its the right technology or tool for the job, but is based on other factors like the company you work for has a cool licensing agreement with a vendor and wants to use their technology because they don’t have to fork out for something more appropriate? This, using a square-peg to fill a round hole approach, in variably leads to difficulties.

Have “simpler menus”! We need to get rid of up-front complicated over-architected designs, and over analysing solutions – which are a product of old-style waterfall approaches. Teams need to be moving towards iterative, agile development methodologies. These processes engage the customers who are able to provide feedback on the product at the end of each iteration so this approach to developing software encourages customers to change their requirements if and when they want to which means that when you finally deliver … your actually giving them what they want! And this squarely puts the customer first!

Keep management out of the kitchen. If your the kind of organisation willing to invest in bringing a smart bunch of technical people together, then trust them to do their job. They don’t need project managers standing over their shoulders asking them for an hourly update on their progress. This kind of Orwellian micro-management is culturally ingrained into some large software companies and in my opinion it is very, very damaging. It fosters resentment, encourages bullying and totally de-motivates developers because of the perpetual monkey on their backs!

I am so glad im not working for an organisation that suffers from these problems, and perhaps if you are then maybe you should consider a change?