I've been working on my CFUnited presentation titled "Reviving the Lost Craft of Writing Specifications" and thought I'd publish a teaser that might make it into the final version. This is raw, rough, uncut and unedited so beware.
//
Sometimes, a client knows what they want in the end, but really truly can't tell you all the component pieces to get to that goal. One day, you get around to reading Robinson Crusoe and fall in love with living in a tree house. You know that a tree house is exactly what you need to make yourself happy forever and ever. So you hire an architect, buy them a copy of Robinson Crusoe and tell them that you want a tree house like the one in the book, only modernized. The iterative programming folks would have you climb up in the tree every day with the work crews while they saw and nail and screw and prune, asking you questions while you're in the tree about attachment points, wind-shear factors and various things you know that Robinson didn't think about when he was building his tree house because they weren't in the book. After the structural builders are done, the trim guys are up in the house every day putting up crown molding and running pipes and lights and they keep asking you questions like, "Would you prefer the 15 watt halogen soft-white bulbs or the 45 watt incandescent natural glow bulbs in these pendant lights?" If you wanted to be wrapped up in that level of detail, you'd have built the damn thing yourself. Sometimes you just want someone else to execute your vision. You pick a dynamite tree-house builder, someone with dozens of houses under their belt, especially of the shipwrecked-looking-variety, you read them some passages from Robinson Crusoe and then tell them to call you when it's done. And if you pick a really good builder, it'll be just like you dreamed it would be.
To be the software developer equivalent of this latter type of builder, you need to do two things well: learn and communicate. The learning comes from your ability to rapidly acquire a deep and wide understanding of the business domain at hand. If it's the futures trading market, you need to learn the difference between a pork belly and a cheddar barrel, a short sell and a long put. If it's healthcare billing, you need to learn the difference between CPTs, DMEs, and CCIs. If it's electronics manufacturing, you need to learn the difference between servo motors, teach pendants, PLBs and weld tips. In order to get that understanding of the domain, you need to be a good communicator, and get buddy-buddy with another good communicator who already is an expert of the domain you're learning (generally called the "subject matter expert"). If you become a domain expert, you can translate the fuzzy, ambiguous ideas that your customer spouts out into a workable software design, and the whole time, poke holes in his harebrained schemes that won't work because of domain rules.
Once you're a really good builder, you can make customers feel involved in a process in which they are ultimately not involved by offering them lipstick-on-a-pig options, like with the style sheet. Should the logo be more "swooshy"? How about adding a horizontal rule between the sub-navs? Some customers dig this kind of interaction. Some don't want to be bothered.
Getting to the point where you are a really good builder also has a drawback: You are opinionated and must express those opinions in the face of potential scorn. It goes something like this:
A not-so-experienced builder will dutifully take notes during meetings, distill the essence of a decision into the spec doc, send out the spec doc for review and ensure that the finished application follows the guidelines set out in the spec doc. If you're building a social-networking app to let users watch paint drying, and your customer requires that all users log in just to view other people's paint drying, you'll spec it as such and build it as such.
But an experienced builder would be able to cross over into the business-decision making arena and question why the customer wants to force viewers of drying paint to log in. What's the overriding business need for that? Won't it place an onerous burden on the casual viewer who wants to check out some drying paint? The natural answer from the customer would be that they want to capture email addresses and some other contact information to sell other complimentary services (like watching grass grow) to people who watch paint dry. The experienced builder suggests a compromise: Let any visitor view drying paint, say, twice on the first day that they visit the site. If they want to view a third, they are gently prompted to register with just their email address. Or if they come back tomorrow and watch some more paint dry, we have a pretty good idea that they're habitual boredom-seekers, so they certainly might be interested in watching grass grow or waiting for kettles to boil. Through a slight change in the requirements of the system, you're collecting a fraction of the email addresses that the customer's proposed way would have collected, but all of the emails collected in your way are pre-qualified. That is, they're actually boredom junkies as opposed to just people who StumbleUpon the site. That, along with the fact that pre-registration is proven to turn off users, so some of those genuinely bored visitors might not have even viewed that FIRST drying paint if they were forced to enter their email address in the beginning. This kind of critical thinking and collaboration on your part is what separates the merely adequate from the really good application builders.
