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
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: Scene from Anchorman 2, Courtesy of Paramount Pictures “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. 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. 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 Part the programmer writes: Given the Wobbly app with GPS enabled 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… Things a programmer can do
Do’s and Don’ts with a customer
Do’s and Don’ts with programmers
Behaviour Driven Development
The old requirement document way:
The new BDD way:
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
When I start the App,
Then a new GPS location is acquired
And send back to Parse.com back-end.