Thursday, January 26, 2012

Why good customer service matters?

I am not an Apple fan, but I do like their computers, and recommend them to colleagues and friends for a variety of reasons. They are well designed, and in addition to an excellent user interface, they run a flavor of Unix--which makes the life of computer programmers a lot easier. But most importantly, Apple's customer support is impeccable, that despite all the hardware issues I experienced in the past, I still recommend Apple computers. Let me explain why.

A year and a half ago, I bought a Mac Book Pro for work. At the time it was the first generation unibody laptop, that had an i7 processor, lots of memory, and lots of disk space. Alas, like first generation models everywhere, it also had a lot of hardware problems. The most annoying of which was the screen randomly turning dark, with the hard drive spinning out of control. The only way to get out of this state was by forcing a reboot by holding down the power button, and losing everything I have been working on.

At first I thought it was a software problem, but after searching the Internet, I found that a lot of people are experiencing similar issues with this generation macbook pro. On Apple's discussion boards there were threads 50 pages long of people having the same issues, with stories about faulty logic boards, bad graphics chips, and bad memory chips. I was furious that I got a lemon for an expensive laptop, and went raging to the apple site to file a complaint.

Unlike other sites, the support links were front and center. I selected my computer model, entered the serial number, and wrote in the problem description. The next screen asked for my contact information--phone number and email, but the third screen diffused my anger. It asked if Apple can call me now, and when I clicked yes, I immediately got a callback, and talked to a tech support engineer within 30 seconds. The tech was very helpful, he diagnosed the problem, and scheduled a same day appointment for me to the nearest Apple store. When I went there, the service was quick, and I got replacement parts the next day. Today nothing on my Macbook pro is original, apart from the unibody, keyboard, and LCD screen.

The whole experience was so delightful, that despite starting with a lemon laptop, I still recommend Apple products. And at my current company, I retell that story, to make sure we delight our customers with exceptional customer support.

Wednesday, January 18, 2012

On cyclomatic complexity

Not all of us are lucky to work with greenfield projects; the majority end up working with codebases that we inherit. These codebases have had their share of modifications that moved them away from the original elegant design: bug fixes, feature additions, and enhancements that were done in a hurry because of delivery pressure, without regard to code hygiene and future maintainability. The code then feels heavy, complex, hard to understand and more painful to maintain.

There are a lot of ways to characterize code complexity, but the one that jumps to mind is "cyclomatic complexity" described by the McCabe paper from 1976  The paper describes how to measure the cyclomatic complexity of different program control paths, and recommends a bound of 10 for manageable code complexity. NIST also selects the same number The numbers, despite being arbitrary, provide a guideline to when to get out the scalpel, and start cleaning up the code.

I was curious about how our code fares, and luckily I found a lot of open source tools that help with that. For C/C++ programs "cccc" is good. If you're using the ports systems,

sudo port install cccc

does the trick. For Java code there are a lot of plugins for various IDEs, and for NetBeans, Simple Code Metrics is good. The plugin page shows that it is old and unmaintained, however it works perfectly in NetBeans 7.1. You choose a file or a package, and click the SCM icon, and it spits out metrics about the code including the cyclomatic complexity.

When I ran the tests, the results were an eye-opener. The good news is that most of the code has a complexity below 15, with the occasional function that is high up in the 30s. Not alarming, but definitely would need attention to keep the code hygiene high. The surprise came when I included some of the open source libraries that we use, and the numbers shot up as high as 206. When I talked to colleagues from other companies, the experiences were similar--most of the normal code hovers around 20, with the occasional function around 50, but no high alarming numbers like the 206 one.