[unrev-II] Re: Views for Software Development

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Wed Jun 14 2000 - 14:43:35 PDT

  • Next message: Lee Iverson: "[unrev-II] OHS ZWiki ground rules"

    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:
     1) Software-support is a highly desirable aspect of the
        system that will help it evolve.

     2) However, by the same token, it introduces a number of
        complexities that are unique to software support.

     3) The set of software-designers is a subset of the people
        who could use a good online discussion tool.

     4) 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.)

     5) 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.

     6) 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:

      a) We are only designing to make sure the data structures are
         appropriate, but we don't plan to implement any of this.

      b) 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.

    ------------------------------------------------------------------------
    Take your development to new heights. Work with clients like Dell and
    pcOrder. Submit your resume to jobs@liaison.com. Visit us at
    http://click.egroups.com/1/4358/4/_/444287/_/961018971/
    ------------------------------------------------------------------------

    Community email addresses:
      Post message: unrev-II@onelist.com
      Subscribe: unrev-II-subscribe@onelist.com
      Unsubscribe: unrev-II-unsubscribe@onelist.com
      List owner: unrev-II-owner@onelist.com

    Shortcut URL to this page:
      http://www.onelist.com/community/unrev-II



    This archive was generated by hypermail 2b29 : Wed Jun 14 2000 - 14:51:09 PDT