In my last blog I started talking about the power of analogy and metaphor, and dove into a discussion of the first analogy of my collection, asking what if the practice of law, rather than being like a domain suffering the consequences of a “failure of openness,” was more like an example of a domain with a great deal of openness. I promised to offer some ideas for analogies that helped make sense of the situation in my next blog.
I was subsequently intrigued by where some of the comments to the post (unexpectedly) led me; thus, I postpone those (original) ideas in order to share some of where those comments led me on the path toward new ones. In this post, I will address the first of two substantive issues: the analogy made by CDarklock between the legal profession and open source software development (--in his view, to the disadvantage of OSSD).
Comparing “do-it-yourself lawyering” with “do-it-yourself usability,” he implies a lack of sensitivity among developers to the risks of the latter relative to the legal profession’s diligence with respect to the former.
Surely enough, when pointed to Groklaw by stats for all, front and center is a warning of the risks of the former:
IANAL. I am a journalist with a paralegal background, so if you have a legal problem and want advice, please hire an attorney.
This prompted me to think about some quick phenomenological test to determine if similar evidence for this type of distinction made by journalists commenting on law (Groklaw) might in fact be recognized with equal alacrity by open source developers commenting on usability: in fact, in defense of OSS developers, there are indeed cases of IANAUE (“I Am Not A Usability Engineer”)—although AFAIK it has not made Wikipedia yet, in contrast to variants of the apparently fecund IANAL which has spawned IANYL, TINLA, and IAAL. (WTF?)
At this point you’re probably wondering why I was so engaged on this topic—the first reason is that, IMHO, challenges with consistent and effective usability practices are endemic and impactful. (I will never forget my introduction to the usability disipline: I was helping usability engineers build a stochastic model on top of their user observational testing of a web experience which (thankfully) has since been improved. The model was pretty cool as a quantification of how much customer time and effort things like ambiguous terms and redundant links actually wasted—but nothing seared the importance of usability into my brain like watching a test subject (a middle-aged, tech-savvy woman with, as I recall, a PhD—kind of hard to blame the user) actually start to cry in frustration as she tried to complete a task.)
The second reason is that I had never considered the possibility of an analogy between “ legal self-representation” and “developer self-usability” as conceptually similar problems to be solved. This analogy offers a different (and interesting) way to think about why it occurs and what to do about it in OSSD, in contrast to traditional corporate development where the origins of usability challenges nor their resolution seem to me to be fairly straightforward: does a company (or development group) recognize the value of good practices, resource for it, make it a priority, test against user interaction metrics etc.
In fact that there is a paper (Nichols & Twidale, online at First Monday) which provides a comprehensive assessment of usability in OSSD, with suggestions for remediation that come awfully close to echoing ideas for what folks in the legal profession would call increasing access to justice (--like academic volunteerism and corporate involvement).
It’s an interesting line of thinking both because it is just in time for CSCW 2006 (Computer Supported Cooperative Work—anybody going?) and because folks in the OSS community (just like in the legal community) are doing some “out of the box thinking.” I’ve been trading mails with a PhD candidate at Penn State who has outlined a very thoughtful research agenda on OSS and Usability—I’m pleased to say we’ll be bringing her to Port25 for an interview near the end of October.
With that said, the next point release on our path to part 2 will address an issue raised by ssjdrn who surfaces (in my words) a tension between two principles I have always taken for granted: efficient signaling and disciplinary control through normalization that is keeping me up at night (literally—when Spence and Foucault, respectively, aren’t jibing for me, I can’t sleep. You can ask my wife.)
And yes, it all does come back to an even richer –than-anticipated analogy between law and open around making successful software.