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.
1 Response to “G'day Project Borat”
Sorry, comments are closed for this article.
June 14th, 2006 at 02:34 AM I definitely think some translation is necessary on both sides of the client:provider relationship, and a good relationship requires a common vocabulary to talk about what they're trying to accomplish. Once the hurdle of common language is cleared, the issue becomes managing the knowledge that surrounds and defines a project. Good software requires a _lot_ of knowledge, certainly more than can be fit into anyone's head at the same time. Of course, everyone has different ways of managing knowledge. For example, I have a difficult time with wikis, but index cards are a god-send. Learning about techniques and tools such as wikis or index cards or use cases or UML is important, because it enlarges one's vocabulary for expressing and managing knowledge. Even if a particular tool doesn't suit your style, it's important to know about it, especially if it "clicks" for the people you work with. I think the most important part about artifacts and processes is that they aren't worth anything in and of themselves. Standing alone, they have little inherent value, and it's impossible to judge them qualitatively. What make artifacts and processes valuable is the context they're used in -- if their users understand them and wield them effectively. So, all that said -- the focus of development relationships should be on the quality of the communication and the management of knowledge. What techniques are used is inconsequential so long as they work!