From: Billy Brown (ewbrownv@mindspring.com)
Date: Sat Jul 10 1999 - 22:16:34 MDT
Bryan Moss wrote:
> The thing I don't understand is *when* you do this count. Do the
> programmers just keep a log of every mistake they make? Do you count your
> defects up after the product ships. For instance, in this e-mail do I
count
> just the errors per line when I send it or while I'm typing (I just went
to
> type 'while' and started with an 'h' - 'started' just went through about
> three different erroneous phases - 'phases' just came out as 'pahses' - I
> just misspelled (correctly) the misspelling of 'phases'... and so on)? In
> short, when do you stop correcting and start counting?
Think in terms of team development. A programmer gets assigned a piece of
the project, writes code for it, does whatever personal testing he feels
necessary, then checks it into the central code repository (which is
presumeably some sort of version-control package). Once he checks it in for
the first time, anything that anyone ever finds wrong with it counts as an
error.
> The UI could handle any possibility but as I said the programmer would
have
> to be removed from the interface. You would have to use a standardised
> document object model so that, in the true spirit of Opendoc, components
> acted on documents. The UI would be a challenge for sure, but it's about
> time someone did something in UI-design rather than just speculating about
> the wonders of speech-recognition. (Won't speech recognition interfaces
> require this sort of component-based model anyway?)
The easy approach to this has already been done (see the MS Office features
for imbedding ActiveX objects in a document, for example). However, that
doesn't let the components modify each other's data.
For seamless integration you need to have a universal data format that all
possible components can read. That's fine for features we've already
thought of, but the first truly innovative product that comes along will
need some kind of data that we didn't allow for in the spec. So far, I
haven't heard of a solution to that problem.
> This requires self-organising interfaces. Self-organising interfaces
> require semantics-rich documents. Semantics-rich documents require
> context-aware user environments. Context-aware user environments require
> self-organising interfaces.
and
> It's worth trying, I think. What I'd like to see is a test-bed for this
and
> other ideas. A semantics-rich context-aware self-organising user
> environment with a hyperlinking file system. I've got it all worked out,
> now all I need is an army of programmers with too much time on
> their hands.
And you were concerned about code bloat in existing systems? You haven't
seen anything yet! Yes, this could probably be done with enough effort, but
the result would expend vast amounts of space on meta-data, adaptive code,
and low-order AI software. Since it would need to be an OS function, that
means we get to add even more millions of lines of code to Windows (and it
will be really, really trouble-prone code, at that).
Even then it would never work very well. We can make auto-generating user
interfaces, but we can't make an AI that knows how to make it useable. Odds
are we would end up back in dialog box hell, or some close variant thereof.
Billy Brown, MCSE+I
ewbrownv@mindspring.com
This archive was generated by hypermail 2.1.5 : Fri Nov 01 2002 - 15:04:27 MST