Copyright 2008-2009, Paul Jackson, all rights reserved
A couple years ago, my wife and I decided to sign up for eHarmony. You know, the Internet dating service with the patented, million-point matchmaking system?
Yes, we were already married. No, we weren’t having trouble and needing to know what was out there.
It was kitten’s suggestion. (I call my wife “kitten”, the reason for which I explain on my kayaking blog.)
Her theory was that we’d both sign up and see if eHarmony’s sophisticated algorithms would match us with each other. “It’ll be fun,” she said.
Now, as soon as I heard the suggestion, I knew that there was no way this could end well. This was an idea that, upon hearing, you just know is going to screw up your life somehow. But kitten wanted to do it, so I agreed. If I’d only known the true horror of what would come from this, I’d have hacked eHarmony and brought their servers to a grinding halt.
So kitten goes first, signs up, runs through all the questions and, at the end, out pops a list of hundreds, if not thousands, of compatible matches … which, for the low, low price of $49.95 a month, they’ll be happy to put her in contact with.
Then it’s my turn.
I start filling out the questionnaire. Question after question after question … it’s thorough as hell. And I’m answering everything as honestly as I can. I get to the end and ...
See, I'm not sure what would have been worse ... to get to the end and have more matches than her or less. And what would have happened if we weren't in each other's matches? I don't know what would be worse, because none of that's what happened. Instead, I got a message from eHarmony.
It was a nice message. Politely, even cautiously, worded – with the sort of tone people use with mad dogs or, possibly, wild-eyed men running through the streets with firearms. I don't have the exact words, but essentially it said:
We're sorry. Very, very sorry, actually, but there's nothing we can do for you. We have no one in our entire database who we'd even remotely consider subjecting to a date with you. In fact, we won't even try to look anymore.
Keep your money. Put your credit card away. We don't want it. Even if you insist, we still won't take your money -- there's simply nothing we can do for you. Please consider applying the $49.95 per month to a good therapist.
Okay, so I made that last bit about the therapist up, but the rest is the gist of what they said.
That's right ... an online dating service refused to take my money.
For years now, I've been hearing about it from kitten: "You're lucky, because there's no one else who'd have you ... but me, I have options. Hundreds of options. Thousands, maybe. You? You got no options."
I can't even really argue with her.
What does this have to do with software development?
Well, eHarmony did something hard ... they told the customer "no".
They could have taken my money and matched me up with whatever hopeless, unmatchable women they let into the service to accommodate guys like me. After all, eHarmony didn't know I was already married and just wanting to see what the list looked like ... from their perspective, I was a real customer, and what I wanted was to join a dating service, right? They could have even told me "outlook looks bleak, but we'll try" and taken my money.
So as a customer, I told them what I wanted: to join a dating service. And they told me "no".
They told me "no", because they looked beyond what I said I wanted to what would really meet my underlying requirement -- joining the dating service isn't the requirement, it's what the customer thinks is the requirement. The real requirement is to be meet someone compatible. They looked at what the customer really needed and said "no, we can't do that".
If they went ahead and just did what the customer asked, let me join, despite my apparently unmatchable personality, I would have been a dissatisfied customer. But their business-model is built on success-rates, not raw numbers, so they said, “no”.
Telling the customer "no" is hard. Whether as a consultant or as an employee where the customer is your business-user. It's hard because that customer's paying the bills ... he's got the money ... and he's telling you exactly what he wants. But what they want may not get them what they need ... and what they need may not be achievable.
One of the first projects I ever worked on was a program for the court clerk in traffic court. As the judge heard cases, the clerk was to use the program to capture the outcome and sentence, then it would generate all the right paperwork. The customer said they needed to see every option on screen at the same time. All the controls to capture verdict, adjudication, probation, fines, jail time, community service ... everything had to be on the screen at once. The customer said that's what they wanted.
Visual Basic 1.0 -- we quickly ran out of GDI handles, stooping to putting graphics containers on the form and drawing the static text in order to free up the handles from the labels.
We ran out of screen space -- this was when the typical resolution was 640x480, but $500 ATI graphics cards got us up to 1024x768 and solved that problem.
The user's couldn't see the small controls at that resolution, too small. $1500, 17" NEC monitors solved that one for us.
Clerk of Courts, remember -- it's a government contract so money is no object.
And the customer got what they asked for. They hated it. That user-interface sucked.
Then we went to write a similar application for criminal court. How'd we get that contract when the traffic app sucked? It's local politics, you don't want to know the things the owner of that company did to keep their business.
So we meet with the criminal clerks to find out their requirements, and what do you think they want? One of the first things they say is, "everything has to be right there on the screen all the time."
This time we said, "no." This time we asked, "why?"
Turns out, it wasn't about the user being able to see everything at once, it was about speed. They had to get to things fast enough to keep up with the judge speaking. Being able to get to things quickly enough was the real requirement, not having everything visible at once. They weren’t giving us the requirement when they said “everything on screen at once”, they were giving us the technical solution.
The real requirement was one we could meet in other ways, and the criminal application was much better and more usable than the traffic app.
The first time around, we did what the customer told us they wanted -- we let the customer drive the technical solution, instead of having them articulate the problem and then presenting them with a solution.
I've always been glad that I encountered that early in my career, because I've seen the same sort of “requirement” over and over again and that lesson has always served as a reminder to look beyond the customer’s statements – and tell the customer that we aren’t going to do it that way.
As software developers, we should be prepared to analyze every requirement under the microscope of “why”, get to the real, underlying need that the customer has, and present them with a technical solution that meets their real needs.
We also need to manage their expectations – just like eHarmony does.
I recently joined a project and I find myself saying something quite often in response to the customer’s requirements: “Instantaneous is not a service-level agreement.”
Some of the customers have an unrealistic expectations – as unrealistic, apparently, as my finding someone other than kitten who’ll put up with me.
If I don’t manage that expectation and tell them, “no, you will not get an ‘instantaneous’ response to your request, it will actually take some time”, then they’ll be dissatisfied with the result and the project will have failed.
It’s hard and they don’t like it, but we have to remember to do it.
Today, a customer asked us to change the key that moves the focus from field-to-field in a Windows application from Tab to the semi-colon (;). I’ll be telling them “no”.