THE WELCH COMPANY
440 Davis Court #1602
San Francisco, CA 94111-2496
415 781 5700


S U M M A R Y


DIARY: August 25, 2000 09:12 PM Friday; Rod Welch

DKR planning for legacy tools to import existing record.

1...Summary/Objective
2...Eric Supports Importance of Importing Personal Information


..............
Click here to comment!

CONTACTS 
0201 - Armstrong Consulting                 650 845 1782
020101 - Mr. Eric Armstrong
020102 - eric.armstrong@eng.sun.com

SUBJECTS
Email Compatibility Prior Email with New System, Nicholas Carrol, 000
Email Core Capability DKR, Collaboration, Eric, 000505
Stable Record Import Legacy Compabitility History, 000227
History Case Studies, Root Causes
History Prior Work Useful Sometimes
History Experience Diary Intelligence
Stable Technology, Avoids Constant Change
Stable Technology Needed Improve Management Productivity
Import Other People's Data Less Important than Functionality,
Import Personal Records Important to Success Software

2212 -    ..
2213 - Summary/Objective
2214 -
221401 - Follow up ref SDS 28 E9R2.
221402 -
221403 - Received ref DRT 1 0001 from Eric Armstrong following up his letters
221404 - yesterday reporting on meeting with Doug Engelbart about system
221405 - architeture. ref SDS 29 0001
221406 -
221407 - Today, Eric discusses the merits of "import" capability called out on
221408 - 000812 by Nicholas Carrol and Henry van Eykan. ref SDS 28 E9R2
221409 - Nicholas asked...
221410 -
221411 -     How do I bring all my old email into the OHS-EC (email client)?
221412 -     I'm pretty reluctant to leave it all behind. ref DRP 7 0002
221413 -
221414 -     How do I get my email *out* of the EC. After all, free email
221415 -     clients at Yahoo and Iname really suck, and maybe this is more of
221416 -     the same. What if I don't like your product, huh? You're not going
221417 -     to trick me with proprietary formats again, Bill Gates!
221418 -     ref DRP 7 P44L
221419 - ..
221420 - Henry van Eykan noted that people build up a substantial stock
221421 - of files that are useful over a lifetime, ref SDS 28 GP3N, and argued
221422 - this electronic memory aids human thinking and so must remain
221423 - unscathed throughout a lifetime no matter what twists and turns the
221424 - art of computing takes. ref SDS 28 4R6H
221425 -
221426 - Eric says...
221427 -
221428 -     It seems to [me] that a lot of people who come out with new
221429 -     systems try to include import functions so that they can [import]
221430 -     data from other systems into theirs. ref DRT 1 0001
221431 -
221432 -     But you know what? The success of the system is hardly ever
221433 -     determined by your ability to read other people's data. The
221434 -     success is determined by what the system can do. ref DRT 1 MO6G
221435 -
221436 -        Eric's comments expressly relate to importing "other people's
221437 -        data," which is nominally different from Nicholas' and Henry's
221438 -        point on 000812 about the need to import one's own data into a
221439 -        new work environment as technology changes.  Below, Eric
221440 -        emphasises importance of importing one's own data. ref SDS 0
221441 -        IM8K
221442 -
221443 -        This is likely a distinction without a material difference,
221444 -        however, since it is critical to be able to render information
221445 -        from any source into a form that it can be processed by tools
221446 -        for aiding human thinking.
221447 -
221448 -           [On 000920 letter to Henry van Eykan supports call for
221449 -           stability of record over time. ref SDS 30 2V5F
221450 -
221451 -
221452 - Eric continues...
221453 -
221454 -     Now, if [a new software program] is successful, crowds of users
221455 -     may demand import capabilities. If so, it makes sense to deliver
221456 -     it.  On the other hand, all the effort that goes into designing
221457 -     legacy-compatibility *at the outset* (note the stress) is time
221458 -     that takes away from the real success-proposition: the system
221459 -     functionality. ref DRT 1 HT6N
221460 -
221461 -        Some authorities cite a "features fallacy" contending that
221462 -        functionality, per se, is less important than usability, i.e.,
221463 -        ease of use, and that a big part of usability is to continue
221464 -        working with the prior record, rather than having to stop and
221465 -        convert everything, see for example Landauer on 950710.
221466 -        ref SDS 1 BWS3
221467 -
221468 -
221469 -  ..
221470 - Eric Supports Importance of Importing Personal Information
221471 -
221472 -
221473 -     ...future compatibility with one's *own* system is an absolute
221474 -     requirement. Oracle made it big by protecting people's investment
221475 -     in their data, so that old databases were directly usable 90% of
221476 -     the time when an upgrade came out. And the other 10% of the time,
221477 -     the conversion was totally automated! ref DRT 1 ZO7K
221478 -
221479 -     Once people put information into the system, the system has to
221480 -     honor that effort. It has to protect and preserve that data by
221481 -     whatever means necessary, defending it against file corruption,
221482 -     hardware failures, and software failures. ref DRT 1 009L
221483 -
221484 -     But making it interact with old systems?  No. That is the hallmark
221485 -     of all the "first tier" technologies that never go anywhere.  In
221486 -     the hardware world, every 4 or 5 years a new processor came out,
221487 -     and for the first year there was always a few companies selling
221488 -     computers with both chips. Those systems always sold like the
221489 -     turkeys they were, and in 12 months the only players left standing
221490 -     were the ones with systems designed around the new chip -- if it
221491 -     was any good. ref DRT 1 005K
221492 -
221493 -     There are major new technologies available today that we can
221494 -     design the system around. Working to achieve legacy-system
221495 -     compatibility (at this early stage) only hamstrings the design,
221496 -     siphons away energy that could be devoted to increasing
221497 -     functionality, and has only dubious value with respect to
221498 -     increasing the system's appeal. ref DRT 1 00EN
221499 -
221500 -        Need clarification, example from Eric on following...
221501 -
221502 -        There may be a distinction between hardware and software to the
221503 -        extent that hardware is a tool to help generate and manipulate
221504 -        information, knowledge and ideas.  Software is the record of
221505 -        information, knowledge and ideas which must be preserved in a
221506 -        form that it can continue to be processed by new tools.
221507 -
221508 -
221509 -
221510 -
221511 -
221512 -
221513 -
221514 -
221515 -
2216 -
Distribution. . . . See "CONTACTS"