Michael - Sorry for the delay in responding to your post.
> From: "Michael W. Wellman" <[EMAIL PROTECTED]>
>> Paul, I fear you've missed my point. Everything you say is true *from within
>> the computer community*, but of little relevance outside.
>
> I know more than a few people who never buy the first generation of a new car
> model. Or of a "new technology" (think VCR, LD, DVD, microwaves, wireless
> telephones, cell phones). They've made a conscious choice to give up "new" for
> "reliable". So I don't think this is a problem limited solely to the computer
> community.
Agreed. However, by comparison to the examples you mention, the software
industry changes the fastest, so whereas buying second generation phones,
VCR's or cars, etc gives you that additional peace of mind. Software evolves
so fast that frequently buying yesterdays 'tried and tested' is no more than
a blimp in its evolution, and may well be superseded the following week.
It's my contention that this 'latitude' (laziness?) in releasing unreliable
software has little to do with an industry in its infancy, but everything to
do with the fact that, being software-based, companies can get away with it.
If every time Microsoft wanted to upgrade a software product it had to
engineer all the machine parts, die stamp moulds and revamp its factories
and tool shops - in other words take part in a huge one-off cost outlay with
the kind of manufacturing implications associated with a long production
run, then, surprise surprise, you can bet the software would work first time
out of the box.
>
>> For the millions of people who are not part of these and other forums, they
>> have a right to expect software to function as well as any other product.
>
> A right? That's a bit extreme. Life, liberty, the pursuit of happiness,
> and bug-free software?
Rights come in all shapes and sizes, so we could debate whether or not there
was a moral right. However, as Barry has pointed out, in the UK goods for
sale have to perform as advertised. So yes, definitely a right.
>
>> My partner is a good example. She uses computing for its functionality -
>> word-processing, spreadsheets and addressbook - period.
>
> Well then, the Palm syncing problem wouldn't affect her, now would it? ;-)
Yes it would. She uses an address book.
>
>> She has no interest or time to involve herself further. Nor should she have
>> to. Try telling her after a 14 hour day in the city that she should seek out
>> specialised help groups and log on to sites like MacFixit and she'll laugh in
>> your face.
>
> She'd be better off if you told her that she should seek a better job. And
> adjust a healthier lifestyle. Her life is way out of balance. ;-)
Agreed. <g>
>
>> This is true for many people. They either don't have the aptitude or lack the
>> considerable time - the hours needed to keep abreast of these things. Just as
>> I drive a car, but have not immersed myself in the finer details of its
>> engine history, or own a telephone but couldn't tell you how it works.
>
> Perfect examples. Early models of the car and the telephone were
> cantankerous beasts.
If you're saying software is in its infancy, I'd agree, yet I'm not sure the
above (heavily engineering based) analogy applies to the unseemly race to
release software before it's ready. This is simply a cynical marketing
strategy. Release it early; corner the market, frighten off competition and
then attempt to bring the software up to standard over time. The software
industry may be in its infancy, but its marketing strategy is anything but!
>
> Although I'm appalled that our educational system produces people who can't
> even explain the basics of an internal combustion engine or the
> telephone...*that* scares me. These are, in many ways, the foundations of
> modern technology and society.
Is that remark pointing directly at me? (in response to my suggested lack of
car/phone knowledge, above) Let me know and I'll answer you fully.
>
>> People expect - and have a right to expect, a certain degree of reliability,
>> and it's a simple fact of life that the early release of most software
>> consistently falls woefully short of these standards. (This is a general
>> observation about the whole software industry and ethos, not just Microsoft).
>
> Remember that the commercial software space is perhaps 25 years old (and
> that's stretching some definitions). Note that software at 25 is far more
> complex than cars or telephones were at age 25.
Agreed, and common sense would say this was a good reason for more caution
when releasing a product, not less.
>
> This doesn't mean that the goal isn't ease of use and reliability, it just
> means that the goal is complicated by reality.
No. The goal is complicated by the need to make money. I'd suggest that the
fundamental difference between releasing version 1 of E'Rage and version 2
will be 'time'. Not new-found skills or startling innovation, just the time
needed to get it right.
>
> Designing and implementing good software requires systems tools that just
> don't exist. And which are unlikely to exist in the near future. I say
> systems tools because it's no longer a question of "Does your software
> work?" It's now a question of "Can any component, including those which
> you've never seen and which will be released years after yours, render your
> software unusable?"
You paint a wonderful doomsday scenario, and I'm sure, from where you're
sitting, it's absolutely right. However, from an outsiders point of view,
your points simply reinforce the fact that the software industry needs a
radical shake-up and that the last people capable of supervising that is the
software industry itself.
> Essentially you're trying to deal with the infinite, but you're doing so
> with incredibly finite resources. And the stricter you make your code at
> only accepting "exactly what you want", the more the user base complains
> that "but this should be acceptable as well". So no matter which way you
> go, you lose.
Yup, definitely a radical shake-up needed. This is not the kind of problem
that self-regulation will overcome. <g>
>
> Some current estimates hold that, when first written, there are, on average,
> one bug per line of code. So every line of code you write to eliminate a
> bug typically introduces at least one more...
I rest my case.
Pete.
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
To search the archives:
<http://www.mail-archive.com/entourage-talk%40lists.boingo.com/>
