How To Deal With Customers

I was at a local computer store this afternoon and I overhead a conversation between who I believe to be the owner and a customer. I didn't hear the whole conversation since I walked in half way through, but the part that I did hear I found startling.

The customer was ranting and raving about how much he hated the computer that he had brought in. He was livid about how it constantly lost data, crashed and generally didn't do what he wanted. He kept saying that he was going to try a Mac because of all of the problems.

Instead of talking the man down gently and being generally agreeable the owner decided to get into a verbal fist-fight with the customer. For every knock the customer had against his computer the owner had something to say about it.

"It just turns itself off after an update!" "It doesn't just shut down, it give you 5 minutes to save what you're doing!"

"The screen doesn't work right." "These things work fine. If yours isn't working it's probably a faulty card or something."

The owner kept trying to give the customer reasons that he should stick with a Windows PC.

"The Mac has 1 trillionth the amount of software." "I don't care. It's not a toy, it's a tool. I don't need lots of software, I just need something that allows me to get my work done!"

The icing on the cake came towards the end of the conversation when the owner said, and I quote: "90% of the world can't be wrong."

In this case, I think the customer was angry when he walked in the door. He was looking for a fight. Clearly the owner doesn't have children. If he did he'd have realized what the customer was doing to him. Instead of fighting with the guy, he should have just agreed with all of his points and suggested that he do try a Mac. The customer had already made up his mind that he wanted to try one.
When the customer asked questions that he didn't know the answer to he should have picked up the phone and called one of the Mac stores in town. That would have diffused the situation and earned him some emotional currency. He could have even gone as far as to ask one of the stores if they do rentals or have a try-before-you-buy program. That customer didn't come in to buy anything, he came in for some help. So help him.

If the customer did ultimately decide to go with the Mac, he'd only have good things to say about the store. He'd refer business over to them if anyone asked and was in the PC market. In the age when brick and mortar stores are close to extinction any way that you can distinguish yourself from a faceless web site and earn some emotional currency is worth the price. Yes you might lose a sale, but you'll just have earned some in the future.

Nil Advice

Recently I wrote that one of the things I really like about Objective-C is how it handles nil-values when calling methods. It certainly makes for code that's easier to read however it does have a downside as mentioned by Daniel Jalkut of Red Sweater software. In Don't Coddle Your Code, Daniel writes:

It s also worth noting that LaMarche s defense of nil ing out instance variables hinges on the presumption that messaging nil is safe. True, messaging nil will not cause a crash. But is that safe? Not if it changes the behavior of your code in unpredictable ways.

He goes on to demonstrate his point with some contrived but applicable code:

if ([mDiplomat didReturnGestureOfPeace] == NO)
{
    [[NuclearWarehouse nuclearMissile] launch];
}

Daniel's point is this:

The biggest disservice you can do to your users is to allow them to run code that has unpredictable behavior. The whole point of programming is to make computers accomplish tasks in predictable ways.

I think he makes an excellent point. To paraphrase -- and I'm sure C++ developers will agree -- just because you can do something doesn't mean that you should. This language feature is a boon for those that understand how to use it effectively and design interfaces that work well with it.

Why FizzBuzz is a Great Interview Question

Interviewing can be really hard and stressful. You need to make a decision about how well someone will fit into your organization. That in and of itself is hard enough; combined with the fact that you aren't given anywhere near the amount of time you need to assess their skill level and personally makes it even more difficult.

The best way to assess skill level is to ask questions that give the candidate questions that allow them to demonstrate their knowledge. But what kind of questions should you ask? Given that 199 of out 200 applicants can barely code, it makes sense to ask a question to weed out the 199. FizzBuzz is just the type of question to do this.

FizzBuzz, if you aren't, is a question that asks the candidate to write a simple program. Typically it's proposed similar to the following:

Write a program that prints the numbers from 1 to 100. But for multiples of three print Fizz instead of the number and for the multiples of five print Buzz . For numbers which are multiples of both three and five print FizzBuzz .

This question is specifically targets problem solving skills; something that all good programmers need to have. It also has the advantaged of targeting the 3 most fundamental concepts in computation: sequence, selection, and iteration. That is, it has loops, conditionals and the sequence of them matters to the output.

The way in which the question is asked usually trips people up too. Implementing the program exactly as it's specified will end up working incorrectly. Why? Have a look at this JavaScript implementation:

for (var i=1; i<=100; i++) {
   if (i % 3 === 0 )
      print("Fizz");
   else if (i % 5 === 0)
      print("Buzz");
   else if (i % 3 === 0 && i % 5 === 0)
      print("FizzBuzz");
}

Anything strike you as odd? The last condition is in the wrong place. If the value is divisible by 3 or 5 the if/else construct would have been broken out of in the first 2 conditions.

Whether or not someone gets the correct answer doesn't really matter. What's really being tested is the candidate's ability to convert a problem description into the language of logic in a reasonable amount of time. What's reasonable? Accounting for nerves I'd say it shouldn't take longer than 10 minutes. A good programmer should be able to solve inside of 5.

Some Thoughts on Cocoa and Objective-C

I originally started writing this about a year and a half ago. It's been sitting on my desktop waiting to be published but for one reason or another I never got around to it. My thoughts now seem trite, but it's interesting to look back. One of these days I should write a post that covers the more interesting aspects of Objective-C's design; more than just what's covered here.

---

I've been dipping my toes in Cocoa again lately, and I'm really starting to enjoy it. I first played with Cocoa when I got my first Mac in 2004. I really thought there was something promising there but I couldn't wrap my head around how all the pieces fit together. After being abused by other OOP languages and their GUI frameworks Cocoa seemed really backwards. Delegation instead of subclassing. Freeze dried objects and connections that are brought back to life at runtime, etc. And the language. Why this bizarre language with it's odd syntax?

Each of the choices in isolation appear to be fairly arbitrary, or different for difference's sake. But as you learn more about the development model you can definitely see a method to their madness. The choice of language is a rather interesting one because it forms the foundation of how applications are written for the Mac. So why Objective-C? In order to understand why Cocoa, OS X's native framework is written in it it's important to know where OS X came from.

In the late 80s NeXT Computer was building high end computer workstations for education and businesses. The crown jewel of NeXT was its operating system: NextSTEP. NeXTStep was a performant, object-oriented, preemptively multitasking operating system with a graphical user interface. In order to quickly build the operating system and its application software a very performant, dynamic, reflective language was needed. At the time the best choice was probably a little-known superset of C called Objective-C.

In the early to mid 90s Apple was looking for a successor to its aging operating system. After several failed attempts to build one in-house Apple was approached by NeXT. NeXT convinced Apple that it had the technology that Apple needed. In the end NeXT Computer was bought by Apple, and NeXT Step was transformed into Mac OS X. If you've ever wondered why classes are prefixed with NS in Cocoa now you know why.

I've found Objective-C to be a really interesting and fairly elegant language. One of the more interesting things I found was that Objective-C uses a completely different calling metaphor from traditional OOP languages that I've learned. What most languages refer to as calling methods, Objective-C calls message sending. The distinction is more than skin deep, it's a fundamentally different paradigm. If you're experienced with the mainstream OOP languages you've spent a great deal of time thinking aboout class taxonomy and how classes relate to each other. You're trained to think that classes are types and methods are associated with the types. This makes a lot of sense if you look at the problem from a compiler's perspective. If you know the class and method at compile time then you can statically jump to the appropriate address. It's faster than a dynamic lookup but you pay for the boost in performance and the currency is developer time.

A message sending paradigm on the other hand is quite different. When you want an object to perform some operation you send a message to that object with some arguments. The object that receives the message will dispatch the appropriate method for the message. Typically there is a one-to-one mapping between messages and methods but in some cases you might want to respond to messages that don't correspond to a method.

You might boil the difference between method calls and message sending down to a difference in who is responsible for finding and invoking the appropriate code. In the method calling convention the caller is responsible (via the compiled code) for determining the address to jump to. Message sending on the other hand leaves the receiver of the messag to determine what method to invoke. Another interesting side effect of message sending is that sending a message to a non-existant object is perfectly legal whereas calling a method on a non-existant object is not. In Objective-C sending a message to nil returns nil. You can chain these together without any problems.

    return [[[a firstChild] nextSibling] nextSibling];

As I mentioned earlier, when an object receives a message that it doesn't understand it is allowed to perform any operation that it wants to.

Apple is not going to Open Source OS X

Last week I was listening to episode 203 the MacBreak Weekly Podcast. I agree with most everything that's talked about on the episodes I've listened to and for the most part this one was much the same, except for the one member of the panel insisting that Apple should open source OS X. Let me be one to say that there is absolutely no way that OS X will ever be open sourced. There are so many reasons that this will never happen it's ridiculous. Here's a few off the top of my head:

Traditional computing devices aren't dead yet

The notebook is far from dead. The desktop maybe, but not the notebook. iOS isn't feature rich enough to replace a traditional computer for the vast majority of people. There are lots of places where the OS shines, but for general purpose computing it's not there yet. You can tell that this sentiment is echoed by Apple in the fact that iDevices are treated as satellites that have to sync up with the mothership Mac.

OS X is required for iOS development, why lose out on a sale?

Right now the only platform that you can develop iOS applications on is OS X. The only hardware that you can (legally) run OS X on is a Mac. Apple makes a sizeable amount of revenue off of Mac sales. If they were to open source the platform they'd been losing Mac sales. Why would they want to cut off that revenue stream?

OS X is encumbered

Probably the main reason that Apple will not open source OS X is that it legally can't. Unlike full open source operating systems like Linux, OS X probably contains lots of code that's been licensed from third parties. What code might that be? It could be anything. For an example of this, have a look at OS/2.

Unlike OS X, OS/2 was actually discontinued. Some years later devoted users and businesses that had bought into the operating system wanted it to be open sourced. IBM refused citing licensing problems over some of the code that makes up the OS. This is coming from a company that does a lot of open source work. If they could, I'm sure they would open source it but legally they can't. It's not worth their time or the potential for law suits.

Apple is not going to open source OS X.

Design Matters

It's summer time again, and with summer comes a change in wardrobe. I have two pairs of shorts in my small wardrobe that are extraordinarily similar. They're just about the same color and cut, and fit very well. Where they differ is in the design of their velcro-shut pockets.

Now, I'm not talking about design in the sense of expensive clothing designers. No, no. I'm talking about their general design and the thought that went into it by whoever designed them. Let me explain, as best I can, the general design of the pockets on each of these. Lets call the first pair A and the second pair B.

Pair A was designed as a standard pocket is - a slit on the fabric with a pouch sewn in. The band of velcro is attached right at the top on the inside of the pocket. Pair B on the other hand has a flap that covers the opening of the pocket when it's closed. The soft side velcro strip is attached to the inside of the flap, while the rough side is attached to the outside of the pocket.

Both of these seem fairly straight forward and obvious. But do either of these strike you as bad designs? I can guarantee you that it isn't obvious until you've used this configuration for a little while. Think about it for a minute.

Did you figure it out? That's right! Design A is the bad design. Because the the velco is on the inside of the pocket whenever you try to pull anything out of the pocket your knuckles get scraped on the rough side of the velcro. It's not so bad the first few times but after a while it can wear your knuckles raw. With design B the only the soft side of the velcro will come in contact with your hand.

Now for the $64,000 Question: Which of these designs do you think was on the more expensive pair of shorts? Yeah, that's right. Design A, the scrape-your-knuckles-raw design was more expensive, but that's not what's important. What's important is that design matters. It matters a lot.

When you're designing something you need to really think hard and sweat the details. What you don't think is a problem could turn into real, actual, physical pain for your users.

You're an Artist!

Do you know anyone that refuses to show you what they're working on until it's perfect? I know I do. What drives this person to polish and buff their creation before showing it to the world? I think they do it because they're scared of what people might think. They're scared that someone might ridicule their hard work. To this person I say: don't worry about what other people think. I know it sounds trite, but seriously. If you're too scared to show off your creation then why did you create it?

Putting something out in front of people isn't easy. Everything you create is a piece of art, it says something about you both personally and professionally. It's a very scary thing, but you have to get over that. If you never show people your half-finished project how will you ever know if you're on the right track? I heard an excellent analogy that sums this up very nicely: You can't steer your boat until it leaves the dock.

What's the worst thing that could happen if you show off your creation? If someone tells you what they think that's great! It doesn't matter if it's good feedback or bad. The fact that someone is taking the time to tell you what they think means they have some feelings about what you're doing. And isn't that what you're trying to do? As an artist you should be striving to make people feel something.

What, you don't think you're an artist? Do you know what the definition of artist is?

Artist

n. A person whose creative work shows sensitivity and imagination.

If you've created something from nothing that shows creativity. If it's something that's never existed before, that's imagination. And there's no doubt that a program shows sensitivity. Have you ever used a program or seen some code that you thought was beautiful? I'm sure we all have, that's sensitivity. So, believe it or not but you, a programmer, are an artist. So stop pretending to be something you're not. Create something that people will have feelings about and unleash it on the world.