[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
For Robert Holmgren Re: Development
- Subject: For Robert Holmgren Re: Development
- From: kfrank@xxxxxxxx
- Date: Tue, 6 Jun 95 19:08 EDT
Lets assume for the purpose of this discussion that all 3 of your
examples are valid. By valid, I mean that from your point of
view the functions you describe would be far better implemented
as you describe them, rather than the way they are. To me that
doesn't necessarily translate per se into:
"It simply doesn't matter how we present this kind of
information. It's just a *WASTE OF TIME* reciting these details,
because the response is ALWAYS "go away". It doesn't matter
whether we ask nicely or nastily, whether we take the trouble, as
I have here, to provide compelling documentation, or not. Go
away. If you volunteer detailed comment, examples, demo
routines, whatever -- you're just politely ignored.
If you're nasty, they're defensive. Always there are excuses of
one sort or another, or they deprecate the seriousness of the
problem. Only the bottom line is consistent: No can do. We're
working on something else just now. The point is, there was a
time when these details were deemed important."
>From my point of view there are potentially a large number of
other factors involved. First, power XyWrite users are
generally very bright, very knowledgeable and very opinionated.
The almost unlimited number of ways to do things in XyWrite is
often a two-edged sword from our perspective, since things that
become absolutely essential for one user's approach to the
product are done very differently by another. Thus it is
concievable to me that you could be entirely justified in seeing
things one way, and someone else, perhaps even a developer,
could also be justified in viewing it another way.
Second, as I am sure you know, in many ways building software is
like building a house of cards. This is especially true where,
as happened during the III+ -> Signature -> IV period, as many
as 50 developers were working on the product at one time. Very
often decisions are made by someone for a particular reason that
don't take into account all of the ramifications, and then other
things are built on that decision, and before you know it,
changing that one little thing is not so simple. When that
happens, often we have to weigh the benefits of making the
change against the benefits of leaving it alone. Frankly, one
of the factors in that decision is always how many users care
about the problem; how big an issue is it? One great XyWrite
tradition is attempting wherever possible to provide a range of
default settings and parameters to deal with the way things are
handled to accomodate different users' desires. XyWrite is so
thoroughly riddled with these, implemented for just these
situations, that your statement that "the response is ALWAYS 'go
away'" seems a little overstated.
Also, as in the Windows issue, sometimes major technology changes
result in unfortunate, but unintended by-products. In Windows,
help is handled very differently. We felt, correctly I think,
that we should provide our help file in this format. Certain
DOS functions operate differently in Windows, and if a
development decision was made not to invest the time to bring
C-frames accross to the new product (and I don't know how this
came about) I don't think that is presumptively a lack of
consideration for users, although I can see how you might see it
that way. If that were so, we would not have invested the very
considerable amount of time and money we did in trying to
maintain as high a level of backward compatibility as we have.
No other word processing company has done that. That we didn't
succeed 100% is not grounds for indictment for unresponsiveness
or lack of concern.
I could offer a number of other possible explanations for why, in
a product as incredibly complex as XyWrite, certain things are
done differently than you would like or expect. None of this is
intended to be defensive, and what I would hope is that we would
listen to your point of view, where possible accomodate it, and
both recognize that we may disagree sometimes as well.
I know for a fact that you are a particularly knowledgeable and
technical user, so I am not at all surprised by these examples.
I do intend to look into them, and respond more specifically to
you at some point. What I guess I am trying to say is that we
walk a very delicate tightrope as we try to balance the needs of
all our users against our own legitimate business considerations
and choose what to spend our time on and what not to.
I can't promise you that we will score higher on the number of
things you ask for that we accomodate. I can promise you that
we take you and your requests seriously (by you, here I mean all
users). If it does not seem that way, we will try to do better
and I want you to tell me. But I would have to bet that if you
reflect on it, you would not find any other mainstream word
processing company who would be even a fraction as willing as we
are to entertain and incorporate users' suggestions on such a
technical level. I know for a fact that you personally (and
here I mean you) have been responsible for many changes and
fixes in the product. Perhaps you underestimate your impact, and
that of your colleagues.
K.