Billy Brown wrote:
[Defects per LOC]
> In essence, a defect is anything that makes the program different from
> the spec it is built to. It could be anything from a bug that crashes
> the program to a typo in a dialog box. Different organizations classify
> them differently, and make different decisions about borderline cases,
> but all of the more organized software companies have fairly good
> written standards that their development teams must use. [...]
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?
> Unfortunately, there are good reasons why OpenDoc never went anywhere.
> Your first problem is that it introduces truly horrendous user interface
> problems. Either the UI has to be capable of handling any possible
> component (in which case the components will be too standardized to
> allow for much innovation), or the components get to draw their own
> windows (which leads to dialog-box hell).
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?)
> Your second problem is that most users don't want things to work that
> way. They don't want to have to figure out how to juggle the various
> components on their computer, picking the right combination for whatever
> it is they are doing at the moment. They want you, the programmer, to
> do that for them. Thus, such a system doesn't have much appeal for
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.
> Since most programmers don't want it either (I'd rather invoke the
> component through code), that doesn't leave you with much of a market.
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.