SHUT UP. You had me at
Hello world.

When talking to customers I often notice that Programmers and Customers think they understand each other, but actually they are not on the same page. This is because the customer sees a problem with it’s customers and wants a solution. The programmer sees a technical challenge and wants to solve it the best he can, in order to prove his uber coding skills. Good programmers are obsessed with doing things right. But, when you start, it is even more important to do the right thing. When you’ve released a stable, but ugly V1 and have shown it to the customer, and he agrees that this is what he wants, and his customers use it and understand it. Only then do it right. But from experience I know, this is usually not the case the first & second time, so stop wasting time!

Socrates said, ‘Know thyself.’ I say, ‘Know thy users.’ -Joshua Brewer, Twitter

What the customer says:

“I just want it to work”.

How the programmer translates it:

“Deliver something without a single bug. Oh and perfect user experience for any audience, that includes my grandma and my daughter”.

Don’t blame the programmer. I think a good programmer will never finish anything. Because it is impossible to write something with zero bugs. And you do want a programmer that is passionate about making it as good as possible.

This picture is a bit cliché, but so so true :).

Things a customer can do

Things a programmer can do

Keep replying to each answer with “why do you want to …. “ – attached in front of it, or keep “digging”. Finally, make a summary of what the customer has said.

Example of an actual conversation between me and a customer:

• Customer: “I want a clean, simple user interface.”
• Programmer: “Why do you want to have a simple user interface?”
• Customer: “Because of my target audience.”
• Programmer: “Who is your target audience?”
• Customer: “Elderly people who have bad vision”.
• Programmer: “Okay so high contrast, a big non-curly font is of importance?”
• Customer: “Yes”
• Programmer: “So if I understand correct your definition of a simple user interface is high contrast, big font and it’s non-curly?”

Do’s and Don’ts with a customer

• Challenge what he says, be critical. Don’t agree right a way with everything he says.
• Make a priority list, chances are he will run out of money earlier before all functions are designed.
• Summarize what he says at the end.

Do’s and Don’ts with programmers

Scene from Anchorman 2, Courtesy of Paramount Pictures

• Don’t look him directly in the eyes, programmers usually are a bit more shy and introverted.
• Make it as clear as possible: how many buttons, which color, how many pixels??
• Don’t feed him cookies. Cookies leave online traces. Programmers hate that!
• Make the “definition of done” clear. Is zero bugs the definition? Prepare to sell your Lambo then.

“A wife sends her programmer husband to the grocery store for a loaf of bread. On his way out she says “and while you’re there, get a carton of eggs”. He never returned.” Typical Programmer’s joke that customers don’t seem to understand.

Behaviour Driven Development

From this step I usually deliver a Requirements document, with rough hour estimation. After approval I start developing the product. What I’ve learned is that we need a solid requirement document, but often it’s too technical for the customer to grasp. So to solve this challenge, I’ve started using BDD.

Behavior-driven development (BDD) is a software development methodology in which an application is specified and designed by describing how its behavior should appear to an outside observer.

The old requirement document way:

• The app must show a popup saying “Do you want GPS to be enabled?
• The app must get a new GPS location on startup and send this to the Parse.com back-end.

The new BDD way:

BDD has 2 parts. The part the Customer writes, and the part the programmer writes.

Example of a BDD feature: “only show jobs within user’s own range”

Part the Customer writes:

As a System
I want to know the location of the user
When he uses the app
So that I can serve him jobs which are in his own surroundings

Part the programmer writes:

Given the Wobbly app with GPS enabled
When I start the App,
Then a new GPS location is acquired
And send back to Parse.com back-end.

That’s all for this week! Next week I’ll be writing a post on ways to increase a programmer’s output. I would like to close of this blog post with the “Picture of the week”:

And the award for most Sexy Programmer ‘1978 goes to…. BILL GATES. LADIES LADIES PLEASE TAKE A NUMBER, and get in line…