Maybe the biggest dysfunction of the programming world is that clients (customers if you’re a freelancer; that guy from Marketing if you’re a 9-to-5) will approach developers not with their problem that needs solving, but with a plan for the application they think will solve it. And the developer will, unquestioningly and tragically, implement it.
Your client’s plan will be given to you, bafflingly, as a PowerPoint document. This is your first indication that this person should not be designing a software application on his own. It will be full of vague phrases like “streamlined” and “hard-wired.” At many points in this document, you will not even know what the client is talking about. But you will implement it anyway, shaking your head and saying “If that’s what he wants…”
The problem is that that’s not what your client wants, even if he believes otherwise. And if you implement what he asked for, word-for-word, he will not go away be satisfied.
So what does he really want?
Find the Problem
Don’t misinterpret my mocking our hypothetical client; this situation is not his fault. It’s yours.
Don’t get depressed because you’re taking instructions from someone who writes the word “WEB” in all capital letters as it were an acronym. He’s allowed; you are the IT specialist around here.
Buried somewhere in the plans for his application lies the real problem he is trying to solve, and you need to find it. If you can’t find it, ask. If he can’t explain it, have him show it to you. If you have to, spend the day in customer service, or in the lab, or at the shipping dock with him. You cannot give the client a solution without understanding the problem.
Don’t worry about offending the client by second-guessing him. Make it clear that this is to help you do you job, and trust me, they will appreciate the careful attention you’re giving them. They will be happy.
Create Functional Specs
In an ideal environment, functional specifications would be handed to you by an analyst who’s already hammered everything out with the client, technical specs would come from the architect, and you could dive right in to programming. But you do not work in an ideal environment. Otherwise you would not currently have a guy with pretty-boy hair pressuring you to drop your other projects to start on his, and a boss who wants you to just frickin’ handle it, please, will you?
You need functional specs. If you don’t write them now, start. Don’t try and doctor the client’s original document up and pass it off as the specs. Don’t even copy and paste from it. You can’t be confident that you’re about to develop a working solution for the client until you can write down the problem and a description of how your application will solve it. Functional specs are not only for client buy-in and covering your own ass later, but more importantly they are to verify that you understand the problem and will solve it.
When you’re done, show it to the client. This is his opportunity to tell you that you’ve misunderstood something, or why the application you want to develop isn’t going to work.
Just like with any other kind of writing, creating the functional specs will expose the angles from which you (and the client) haven’t viewed the issue yet, and bring up new questions. It’ll take a few drafts before you’ve got it, but changing a Word document is faster than re-designing database tables.
Use Mock-Ups
Your client doesn’t know what a combo box is. He believes he knows what tabs are, but he’s actually thinking about tree controls.
Mock-ups are invaluable for showing the client how your proposed interface will work, and they take almost no time at all. Drag and drop one up in Visio, or just draw it with a pencil. It doesn’t have to be a work of art, it just has to visually explain what you’ve already described verbally in the specs.
Every screen, popup, and dialog of your interface should be mocked up. A few seconds spent mocking up that one seldom-used input dialog will save you a couple hours fixing it one month from now.
Now Start Coding
And don’t feel like you’ve lost time in getting here. In the end, all the documenting and dialogging with the client will save you time. When you finally start coding, you will move very quickly, without back-tracking and making fewer mistakes.
The first couple times I saw this in action, I was amazed. Projects where only 40% of the time was spent on actual coding finished faster than projects where 90% of the time was spent coding. This really brings into light the difference between software development, which you’ve been doing since the moment your client approached you, and coding. They are not synonymous.
Accept That There Will Be Revisions
You’ve gone through three drafts of the functional specs before the client signed his name to them. You’ve faithfully documented the technical specifications for the application (which is outside the scope of this article, but you did do that, right?) so your co-worker can pick up where you left off after you’re, oh I don’t know, devoured by grizzlies or something. You’ve got a basic, tentatively-bug-free build of your application ready for the client to take a look at, and… he forgot to tell you that he needs to enter last week’s widget price when shipping on Thursdays, otherwise the delivery truck will explode!
Why why WHY didn’t he mention this before? You discussed the application with him at length. You practically wrote that damn functional specs document with him at your side and you even drew him pictures of how it would look! For the love of God could you be working with bigger imbeciles???
The client isn’t an imbecile. Don’t forget that the two of you are breaking new ground here. After all, if applications to solve this exact problem were a dime a dozen, the client could buy it for $99.99 and you’d be shuffling down the cold, cold street with your shopping cart.
As long as your application’s been developed with a solid understanding of the problem its solving, almost any revision can be accommodated without having to go back to square one.
