Welcome to Orcmid's Lair, the playground for family connections, pastimes, and scholarly vocation -- the collected professional and recreational work of Dennis E. Hamilton
What Programmers Do
Eric Gunnerson's C# Compendium : Regular Expression Exercise S1. I am suffering from an episode of blogstipation, struggling with a long piece based on an enquiry into “What Computers Know.” I want that as one foundation for a progression of blog entries to be carried out with my associate, Bill Anderson, and anyone else who chimes in. I’m paving the way toward recognition of the inevitability of the requirements gap between what users do and want and what information technologists understand and build.
My thesis is that the requirements gap is not one that can be closed by a technical solution: that is, by embracing and extending from the IT side, whether called requirements engineering or anything else that sanitizes the life out of what it is that users (and businesses) are really concerned with.
While drafting the foundation piece is wearying, I already have two catch phrases that will be important:
The Heartbreak of Blogstipation
I arose at 4am looking for something more productive than staring at a darkened ceiling fretting about all this stuff. I’m fussing with one little diagram and having a notation that will work to convey what it is I am seeing about the gaps and their technical origin in the nature of digital computers themselves. I have too many thoughts, too few words, and I probably won’t need so many of either once I’ve work through it.
Meanwhile, thanks to Lee Holmes, I have been introduced to the wit and wisdom of Eric Gunnerson. Here are some wonderful illustrations of the problems that we have as software developers in terms of what we sometimes think we are doing.
Eric’s Regular Expression Exercise S1 provides a wonderful illustration for “What Computers Know” and its intended sequel, “What Programmers Know.” For my purposes, it is not important what regular expressions are. It doesn’t matter whether you carry out the exercises (with or without one of the tools for that purpose).
Data Isn’t What It Seems
First, compare this statement of the exercise,
with this alternative,
It is the change in wording that is important, not the tweaking of the typography.
Consider, for the moment, that a string of text may have the form of a social security number but that is not enough information for concluding that it is a social security number. There are additional conditions on social security numbers, and that is without considering whether (1) a string of the format happens to correspond to a social security number that has ever been issued , (2) whether that is the correct social security number of a person that is meant to be identified in this way, (3) whether there is some interchange requirement that makes this specific format a rigid requirement, and (4) whether its just the form of social-security numbers that is used, but that’s not what the data are. I’m sure there is more that could be added to this list.
My supplemental clause, “the format used for social-security numbers,” is completely unnecessary although it might be useful in having someone understand the intended purpose of the operation. It’s presence is also an opportunity for someone to substitute their understanding of what that means and grant themselves liberty to reinterpret the explicit requirement of the exercise. This is the odd risk of too much information.
So, to avoid confusion of what something is with what it might be for, it is worthwhile to be careful about what we say something is (and what we want done with it).
Without Context, All Transformations Are Valid
Secondly, and more interesting, is what people make of Eric’s simple exercise. Notice the wonderful sequence of comments where people argue with the statement of the exercise and vote for a different exercise that is completely out of context (or in a different context not in evidence). And none of them (but for one, perhaps), raise the issue of exactly what is it that is invariant and that must be preserved in Eric’s statement of the exercise. And this happens even though the requirements of the exercise are satisfied simply and directly in the first comment.
I suggest that this is a great illustration of what happens when we operate inside the solution space, isolated from the world of action and opportunity that the users of our products live in. Is it any surprise that there is a terrific gap between what users ask for and what programmers speculate and then do?
Other Food for the Brain
Intrigued to learn what else Eric is fascinated with, I have a few more gleanings for you:
Orcmid, your point about including unneeded information is a good one.
Some of the current requirements specification methods that focus on user personas as proxies for actual users fall into this practice. Personas are constructed to represent a class of user, or even a work role, but then include data such as weight and hair color. These kinds of errors just compound the already difficult problem of articulating requirements for machines that can fit into the work and business lives of the users.
Bill, you took me by surprise there. I had been looking at creating personas for part of my ActiveODMA project work. I posted more about it at the Professor's.
|You are navigating Orcmid's Lair.|