Re: The author of a query is (not) most likely the user

On Jul 4, 2005, at 3:28 PM, Adrian Walker wrote:

>  Hi Bijan --
>
>  Many good points in your posting.  For the list, I'll just try to 
> pick up on one of them here.
>
>  At 02:36 AM 7/4/2005 -0400, you wrote:
>> don't know why it's [a reasoning chain is] so much harder [for people 
>> to understand] than for complex software in 
>>  general. Executable specifications are in the minority of formal 
>>  specifications are in the minority of specifications, as far as a I 
>>  know. "Executable natural language" in the minority of all that.
>>
>> Wow, I'm making a popularity argument. Whoo, how the mighty 
>> Smalltalker 
>>  has fallen :)
>
>  The general thought here is that the mismatch between the business 
> level and the programming level is already very expensive with 
> conventional software. 

Let's grant that.

> (E.g. some years ago, the US DoD IT spend was comparable to the GNP of 
> Australia.) Part of the cost is for techies to understand what the 
> business folks want, and for business folks to understand what the 
> techies have built.  Just look at the 'modelling and specification' 
> costs on any big software project.  And consider too what happens when 
> business requirements change while the system is being programmed.

One way of handling this is with methodology. E.g., the whole eXtreme 
Programming craze.

>  The problem can get worse with rule systems,

Why? What makes the difference? Maybe there's something wrong with rule 
systems (e.g., lack of modularity.)

> if we stick to the techie notations that us techies know and love.  Or 
> it can be mitigated, if we make sure that the person writing the rules 
> has to document what they mean at the real world business level.  If 
> this is done by including lightweight English

"Lightweight English" has no positive, or, indeed, contentful 
association for me. Either the language is regimented, or it isn't (or 
somewhat regimented). If it is executable, it will depart from English 
enough to belie (to my mind) any claim of lightweightedness. As the 
system gets large, the need for structure and (formalisitc) clarity 
seems to go up, not down.

> in the rules themselves, the rules and the documentation cannot get 
> out of step.

Only if the rules themselves are adequate documentation of themselves. 
By "adequate" I mean "epistemically adequate", i.e., that it really is 
the case that a user understands the import and effect and, well, 
meaning of the rule (esp. in combination with other rules).

>   We can also get English explanations of the reasoning.
>
>  We don't yet have HCI  studies to say whether this is a good 
> approach. 

We don't have a clear analysis of what "the problem" (more likely, a 
whole family of problems) is/are. Again, consider today's websites. 
More specifically, ecommerce sites. Though data and query heavy, I'd be 
very surprised if any significant fraction of them provided anything 
more than stack traces on crash by way of explanation. (Or similarly 
techie oriented explanation.) Why not?

[snip]

Cheers,
Bijan Parsia.

Received on Tuesday, 5 July 2005 05:25:00 UTC