Eric Armstrong
eric.armstrong@eng.sun.com
Memorandum
Date: Wed, 14 Jun 2000 14:43:35 -0700
|
From:
|
Eric Armstrong
|
|
eric.armstrong@eng.sun.com>
Reply-To: unrev-II@egroups.com
|
|
Subject:
|
Views for Software Development
|
It's times like this that I wish we were using an IBIS-
constrained system.
One of the wonderful constraints of that system (which I
typically avoid myself, because our system doesn't support
it) is to always put forth a proposition as an answer to
a question -- thereby opening up the fundamental assumptions
for debate, and allowing for alternatives.
IBIS suggests that asking "yes/no" questions is not a good
idea, because it precludes alternatives. So the best question
I can think of is:
- What features are requirements for this system?
To the options presented in the current requirements doc, we
could therefore add:
Support Software.
However, stepping back a level, I think we need to ask,
"What are we doing?"
Are we:
- Following the mandate that originally surfaced on this
list to develop a prototype we can use to carry on more
effective discussions about what the *next* version
should be?
- Designing a complete DKR, from the ground up, with all
the trimmings?
- Making sure the data structures we design will support
our eventual needs, with the explicit desire to restrict
our initial implementation way, way down to something
feasible?
I think it would be a very good idea to clarify our goal,
because I suspect that our discussions and suggestions are
stemming from radically different perspectives on this
subject.
My own personal bias (which I must state in order to leave
myself open to be argued out of it) is:
- Software-support is a highly desirable aspect of the
system that will help it evolve.
-
However, by the same token, it introduces a number of
complexities that are unique to software support.
-
The set of software-designers is a subset of the people
who could use a good online discussion tool.
- For many software folk, you will only pry emacs (vi, or
what-have-you) "from their cold, dead fingers". So they are going to be
less than excited about some new way to edit their software. (But making
sure that software goes both ways between plain text and the system
_without_ _losing_information_ is what creates most of the complexity.)
- The combination of #2, #3, and #4 suggests that the
project increases significantly in scope in order to appeal
to a fractional additional percentage of the population --
a population that is likely to be less attracted to the
system initially, as a result.
- As a result, I have felt that it is in the best interests
of the project to focus on a *design* tool, rather than
a software-management system. (I thank Christine Peterson
for focusing my thoughts on this direction.) My suspicion
is that developers who will not easily be persuaded to
adopted a new source management tool will leap at a
replacement for email -- and that, while they are getting
used to that interface the software support can be tacked
on to the system. (Once they are comfortable with the
system as a discussion tool, I expect the objections to
using it as a software mangaement tool to dwindle.)
The requirements document I put together was focused entirely on a better
interactive discussion tool. It avoided software management completely.
However, I feel we are embarking on an mandate to include software support from
day one. My feeling is that doing so is both a strategic and a tactical
mistake. Tactically, it adds complexity. Strategically, it lengthens
development times and may tend to put off the very early adopters we wish to
attract.
Now, having said all that, there is room for counter-argument. Arguments that
make sense to me include:
- We are only designing to make sure the data structures are
appropriate, but we don't plan to implement any of this.
-
Open Source developers and organizations we know have told
us they want this.
Maybe there are other arguments I haven't thought of, but those
are the only ones that make sense to me at the moment.
Sincerely,
Eric Armstrong
eric.armstrong@eng.sun.com