G'day Project Borat
Yesterday, Project Borat and I were formally introduced. I'll be the lead developer, picking up the thread and, along with Robby, I'll continue to entertain you with insights we gain as we delve deeply into the process, knocking some moss off a few rocks and uncovering ideas that will work well for us and our clients.
As this project is just getting under way, one of the first things we're facing is... hmm, I hate to label it because along with that label comes all sorts of assumptions. Sure, we could call it requirements gathering, but that doesn't tell the whole story. Then there are stories, use cases, method XYZ, and better mention PQR for completeness. Before you run off googling those last two, I made them up. Point is, even though there is a lot of material on processes, and I'm learning more every day, it's just not that simple.
So, today Robby and I took a quick jaunt over to one of my favorite places on the planet. How cool to work this close to Powells Technical Books. While he's deep into today's acquisition, Mastering the Requirements Process, 2nd Ed, I had my own surprise waiting on my doorstep this evening.
That brings me to one point about gathering requirements: the first value listed on the agile manifesto--"Individuals and interactions over processes and tools". I'm guessing there's more than a few reasons why that one is listed first.
Clients are people with varied backgrounds. If we are slaves to a particular methodology, we either 1) talk over the client's head with unintelligible jargon, 2) try to coerce the client into "learning" our methodology so we can "be on the same page", or 3) continually translate, in the back of our heads or on our notes, what the client is saying into our method's jargon. The first two are disrespectful, the last one error prone. (Where's the feedback that must occur for checking understanding?)
When we, as developers, began focusing on user-centric design and usability, it was a recognition that users deserved respect and need not be rescued, if you will, by our bright ideas. In a big way, we needed to keep our bright ideas out of the user's way. In the same way, I'm not convinced I should expect a client to care about stories, use cases, or XYZ artifact. I do believe my role is to facilitate a client's understanding of what they want and capture that as faithfully as possible.
I think plain ol' natural language is probably the most valuable tool for that. "Ee gads, but natural language is fraught with ambiguities, imprecision, double meanings, and all things evil," you say. Well, perhaps. But consider this: mathematics is probably the most precise form of "language" humans have yet devised, and plain ol' natural language suffices to convey mathematics given a couple rules of usage.
First, we do try to eliminate ambiguity and imprecision with definitions. If I'm talking about a metric space, I begin with, "given a set X and a metric d, (X,d)". There, no more ambiguity. And second, economy; introduce a symbol or name to mean a particularly well-defined concept. Add a dose of discipline, be conscientious about usage, and you can get very far using normal language to discuss very difficult concepts. Trust me, or visit a math class and watch people learning math.
So, that's the first of my explorations. How far can natural language take me before I start reaching for this or that "representation"? I'll aim to keep these posts short and pithy in the future, but thanks for ambling along with me on this one.
