Mon, 06 Jun 2005
Threat trees and others
Eric Jarvi
writes a post on threat
trees in response to my post on fine-grained
guidance in exploratory testing. It reminded me of a short paper
by Cem Kaner that I've always liked: Negotiating Testing
Resources: a Collaborative Approach. Should be appealing to
the big
visible charts crowd. I recommend both links to your attention.
## Posted at 11:57 in category /testing
[permalink]
[top]
Form, content, and the structure of relationships
From an op-ed piece by Stanley Fish:
On the first day of my freshman writing class I give the students
this assignment: You will be divided into groups and by the end of
the semester each group will be expected to have created its own
language, complete with a syntax, a lexicon, a text, rules for
translating the text and strategies for teaching your language to
fellow students. The language you create cannot be English or a
slightly coded version of English, but it must be capable of
indicating the distinctions - between tense, number, manner, mood,
agency and the like - that English enables us to make.
You can imagine the reaction of students who think that "syntax" is
something cigarette smokers pay, guess that "lexicon" is the name of a
rebel tribe inhabiting a galaxy far away, and haven't the slightest
idea of what words like "tense," "manner" and "mood" mean. They think
I'm crazy. Yet 14 weeks later - and this happens every time - each
group has produced a language of incredible sophistication and
precision.
(Hat tip to rpg for the link.)
One of my pet obsessions these days is learning and teaching two
guidelines of well-factored code:
- Don't repeat yourself
-
Eliminating duplication seems key, but it's surprising how many
programmers don't care about even the kind of duplication a
program could find, much less subtler forms like boolean
arguments.
And yet, we have people like (I believe) Ralph Johnson saying:
Once and Only Once is a profound concept, but difficult to
apply. I've spent my entire professional life (25 years)
learning how to apply it to programs.
And we have testimonials like Ron Jeffries':
I once saw Beck declare two patches of almost completely
different code to be 'duplication', change them so that they
WERE duplication, and then remove the newly inserted duplication
to come up with something obviously better. [Ron: it would be
tremendous if you could reconstruct the code.]
(Both quotes found here.)
Could we come up with words akin to "tense" and "mood" that make
relationships of duplication clear to people who are
middling language-writers but not language-understanders?
- Intention-revealing names
-
As discussions of good method names show, we don't even
have the right words to express this idea. "Intent" isn't quite
right, and it's not exactly
that good names say "what" vs. "how", and it's not really that names
say "why" - but it is something. How to talk about that
something?
Now, I'm certainly a fan of tacit understanding of what's
inadequately captured by rules, so I don't believe that the two
guidelines above can be completely captured by some syntax governing
relationships, any
more than I believe everything
that natural language does is a matter of syntax. But if a knowledge of
syntactic rules can help English writers, I expect a syntax of
relationships (not the BNF of the language) could help Java
writers.
I'm aware that I'm boldly heading to the 50's and
structuralism,
at least two intellectual fads ago. What of it?
## Posted at 08:51 in category /misc
[permalink]
[top]
|