Results Of PERT Triage

[Marc Stiegler <marcs>]

As noted in the last weekly planning meeting, we recently held 
a triage on the backend, to identify any cuts that could possibly 
be made to the implementation to get the backend to Beta more 
quickly. Triage is of course only held under grim circumstances; 
alas, the reason for holding this meeting was suitably unpleasant. 
We held the triage meeting because my loose but continuous tracking 
of the PERT showed that our shipment date for Beta had slipped 
into January of next year.

With this in mind, the mottos for the triage meeting were:

1. If we had to eliminate this capability, would it be better 
to have no Xanadu at all?

2. Can it wait till Release 1.1?

I had not expected much success in finding parts of the project 
to cut. But in fact, the people of Xanadu showed almost as much 
creativity in eliminating tasks as they have historically shown 
in creating them. We will ship much sooner because of the cuts 
in the plan. 

But we ran into a rather curious effect on the way to the butcher 
shop. First we brainstormed for tasks that at least one person 
in the group thought we might conceivably cut. Lots of things 
to cut came up. Amusingly (the sort of amusement that makes you 
hurt inside), some of the tasks proposed for cutting were tasks 
that HAD NEVER BEEN ON THE PERT CHART IN THE FIRST PLACE. Needless 
to say, some of those heretofore unidentified tasks could NOT 
be cut. They have been ADDED to the PERT.

The upshot is that the chart is much more correct (I've said 
that before, haven't I? And it's always been true; unfortunately, 
we've never had a great indicator of how incorrect the old ones 
were). Our chances of actually completing what we've claimed 
on the PERT have improved. But this hasn't made the dates a lot 
more hopeful. A report on the PERT itself will follow shortly; 
herein reside the results of the triage itself.

ITEMS THAT NEED FURTHER CONSIDERATION:

To what extent must we use backrefs the first time out, as opposed 
to forward refs? (hugh, markm, et. al. need to discuss this)

Do we need coroutine threading? (markm, michael, others as needed)

POST-BETA, BUT BEFORE SHRINKWRAP POSTPONEMENTS:

Walk through of Sun OS to confirm it supports URDI is postponed.

ITEMS POSTPONED FROM RELEASE 1.0

No exposure of Orgls & Berts for third party developers: developers 
will be restricted to the document & links layer, allowing us 
to fix the remaining defects in the orgls & berts layer for 1.1 
(or even 2.0). This, I believe, is the most significant cut in 
development effort--it comes straight out of markm's task line, 
which is a critical path.

No special support for fonts in the backend: fonts will be represented 
as links.

No platforms other than Sun 4 (with one exception, guys, that 
we came to realize after the meeting: we need Sun 3s for Greg 
Lutz).

No variable snarf sizes in URDI.

No device independent URDI.

If URDI is not working well enough to perform recoveries within 
a fixed number of days, we will build a nonrecovering, but error-detecting, 
URDI. Folks, I hereby propose giving this task 10 days, then 
switching plans. If someone wants to propose a shorter number 
of days as the drop-dead, I am interested in hearing the suggestion.

No serial line communication: only LANs with IP will be supported 
in 1.0

POSTPONED TILL LAST MINUTE BEFORE BETA, TO CUT IF POSSIBLE AND 
NECESSARY:

The last thing to do before Beta is to put cleverness into ent 
storage; we will put only as much cleverness into ent storage 
as screams to be done, based on measurements of live performance. 
(as an aside, most performance tuning is already scheduled to 
take place during Beta, when we have live numbers from not only 
ourselves but also others).

OTHER PLANS TO HEIGHTEN PRODUCTIVITY:

System configuration changes must be scheduled with team consensus 
to prevent surprise downtime. Here the term "consensus" does 
not necessarily mean a formal agreement from every member of 
the team, though if I were bill, that would be my conservative 
analysis (bill, let us discuss this another time). A complete 
definition of the term "consensus" in the absence of a unanimous 
vote will be explicated in my forthcoming book, "Management and 
Decision Techniques for the Anarcho Capitalist" :-).

Globals can be used without long harangue in non-shipped products 
(such as stubble).

The development team itself will not spend effort helping developers 
use languages other than C++ to interface to Xanadu. This will 
be undertaken by our developer support person when he/she arrives.

OTHER ISSUES:

Structured debugging offers both hope and peril on the march 
to Beta. The following questions should be asked when considering 
structured debug for each module:

In this module, what is the risk of a BETA-PREVENTING bug? In 
general, a Beta preventing bug is one that might corrupt the 
information pool. As the risk goes up, structured debug is more 
strongly indicated.

In this module, what is the cost of performing structured debug? 
As the cost goes up, structured debug is less strongly indicated.

What is the time savings ON THE WAY TO BETA of performing structured 
debug? If structured debug will probably save time, do it. Otherwise, 
do not.

Finally, an issue of security. Since we may not be presenting 
the berts & orgls layer to the world until 2.0, berts & orgls 
must go back into the black hole where we hold the ent algorithm 
and the visual behavior of the frontend. We should not tell people 
about it except with an extreme need-to-know (i.e., let you and 
me counsel together before telling them, regardless of nondisclosure 
signatures). In the past months the orgls & berts layer has been 
"light gray", since we were going to show it to the world in 
a few months anyway. This is no longer the case.


--marcs