Chicken Little Driven Development - Dealing with Panic

Wed Jul 25 18

There's a problem in the world. So many times software is written to meet the needs of business in a way that's unrealistic to expectations. Just look at the following software projects that met expectations incorrectly

  • McDonalds Kiosks
  • Event Cinemas online booking
  • IBM in general
  • The Linux Kernel

Now you might be looking at this list and asking yourself "what the hell is this guy on about" and to be honest with you, you might be part of the problem. I could see the lack of expectation-meeting and I was fed up with it. My McDonalds Kiosk was unfit for purpose because I had to use 13 taps to order a meal. The Linux kernel had TOO.MANY.HIPSTERS. Event Cinemas online booking was too user focused and lacked the powerful command-line tools I require to do my work. IBM is IBM.

There was only one solution to shitty software deliveries. I took a crack team of designers, UX people and a chihuahua up a mountain and wrote a 16 page manifesto at a ski-resort. We were known as the gang of thirteen-and-a-half. The solution in short is this

  1. Listen to business requirements from stakeholders
  2. Argue with them viciously with everything that might take more than 15 minutes
  3. Begrudgingly implement exactly what they want
  4. Laugh and through peanut shells at them when it's not what they want

We call this "Chicken Little Driven Development" or CLDD for short. The reason behind the name is that quite often, the business will claim the sky is falling when implementing CLDD. That's okay though! It's hilarious. The main advantage of CLDD is developer happiness. It might be a bit too extreme for business partners, but that's only because they don't understand computers the way we do.

In all seriousness, the way a production issue presents itself to the stakeholder will appear to be more of an emergency than it actually is. To be fair when your computer says "System Error" and it looks like it's crashing over and over again and it looks totally unfixable, the average user will be at their wits end. A power user on the other hand will simply know "I just have to hand this over for a fix" and the developer user will say, "Oh it's a small issue, just have to rename a variable". This process of lowering the defcon level of a software problem is how a problem will get fixed.

It's never as bad as it looks. You probably just missed a loop counter

This is what I tell myself almost always. As I get more into the computer configuration side of things, I replace "loop counter" with "config entry in IIS". The user/The BA/The boss/The moneyman will always panic. They're the ones (after all) who are losing their valuable time with the software. It's your duty to help them out as the software developer at his job. You are not doing your duty if you panic. I personally find a multi-point approach is best

  • The above quote works. It's never as bad as it looks
  • Humour (i.e. making fun of users with CLDD or PICNIC protocol "Problem In Chair Not In Computer")
  • Walking around for 10 minutes costs less time than panicking for 30
  • Remember that users did their job for years without your software, and can deal with a bug for a day or two.