Context and expectations

[David M. Lloyd]

I certainly hope that this isn't directed at me, as my post specifically 
calls out the correctness and validity of the requirements, including a 
suggestion for a better idea as an illustration of the weakness of the 
requirement, and did not include any insults or anger, especially 
towards individuals; though it's hard to draw any other conclusion given 
how rarely anyone posts to the jigsaw list from outside of Oracle.

As I've often said in ##java, politeness is always defined in the 
context of one's local culture.  As for me, I'd rather have someone 
directly say "your idea is wrong and here's why" if they feel they have 
a strong argument.  Rejecting discussion that *you* find impolite 
*because* you find it impolite is a very insular attitude, and doesn't 
work well in the greater community which is often far less culturally 
homogeneous than corporations tend to be.  Remember Postel's law.  It's 
far more productive to consider the actual content of the message and 
reply in good faith - only if a message has no valid content is the 
"bozo" bit in scope.

Also, this isn't Congress, it's a public forum - once a question is 
"answered", it is not "closed" especially if it relates directly to the 
validity of requirements or the efficacy of an implementation decision. 
  If you don't allow direct criticism of requirements, the definition 
and understanding of which are the basis of any good software, you've 
cut off pretty much all meaningful input from the community, which would 
make this whole exercise a sham; I'm continuing to give the benefit of 
the doubt on that point, which is why I keep on trying to work with the 
Jigsaw team.

I do think it is clear that many of the requirements in the requirements 
document are implementation directives, and I believe this is a poor way 
to design software.  Implementation directives are *derived* from 
requirements, which in turn are guided by real-world use cases.  For 
each such directive, one must ask, what is the *real* requirement that 
precipitated it?  Chances are there is a very good reason that it seemed 
necessary to give such a directive; but it's the underlying requirement 
that has to be identified, because chances are also very good that there 
are other options to meet it which may be superior (or may not be).  One 
of the key strengths, in my opinion, of Open Source Software is 
recognition of this basic humility and the opportunity it presents for 
us to create software greater than we ourselves would be capable of.

You (and by "you" I mean "all of us in this business") have to be able 
to question your own perspective and accept outside views, and yes this 
*does* mean calling into question your own motivations, *constantly*. 
Is a requirement there because it specifically solves a known problem or 
use case, or because it's just something you want?  Is there a better or 
more concise way to express this requirement?  The answer to these 
questions can mean the difference between good and bad software.  Often 
times we *want* something because of an intuitive understanding of the 
problem - but these things still *must* be expanded and codified, 
because they nearly always contain weaknesses and prejudices (we all 
have them; stature or experience level is no guarantee against this).

So yes, you could say that I question your motivations, because that's a 
responsibility incumbent upon anyone who evaluates requirements gathered 
by another.  It's nothing personal, it's just good engineering.

On 07/19/2012 05:12 PM, mark.reinhold at oracle.com wrote:
> To quote from the Project Jigsaw main page [1]:
>
>    The goal of this Project is to design and implement a standard
>    module system for the Java SE Platform, and to apply that system
>    to the Platform itself and to the JDK.
>
>    Right now this effort is in an exploratory phase in which we are
>    investigating and prototyping various ideas in the context of an
>    in-progress requirements document.  That document, together with
>    the overall Jigsaw design, will be among the starting points of
>    an eventual Java Platform Module System JSR.
>
> That page also contains pointers to additional working and background
> documents.  The most important of those are the requirements [2] and
> the "big picture" overview [3], which together describe the context
> of the design and development work taking place on this list.
>
> Please make sure you're familiar with that context before you post to
> this list.  If you don't agree with it, that's fine -- ask questions.
> If you have a better idea, that's great -- please suggest it.
>
> Do not expect, however, that asking questions that've already been
> answered, attacking the motivations or intelligence of those of us
> who've been working on this for a long time, casting insults, getting
> angry, or otherwise behaving impolitely will have any effect other
> than to set your bozo bit.
>
> - Mark
>
>
> [1] http://openjdk.java.net/projects/jigsaw/
> [2] http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12
> [3] http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01


-- 
- DML