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