[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Results Of PERT Triage
- To: <us>
- Subject: Results Of PERT Triage
- From: Marc Stiegler <marcs>
- Date: Sun, 13 Aug 89 20:05:11 PDT
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
No platforms other than Sun 4 (with one exception, guys, that
we came to realize after the meeting: we need Sun 3s for Greg
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
POSTPONED TILL LAST MINUTE BEFORE BETA, TO CUT IF POSSIBLE AND
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.
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
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,
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.