xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Leung" <twle...@sauria.com>
Subject Re: Mixing Two Terminologies
Date Sat, 03 Mar 2001 07:34:03 GMT
First of all,

Thank you both, Arved and Kimbro, for participating in this discussion
and tolerating me when I get too excited...
----- Original Message -----
>From: "Arved Sandstrom" <Arved_37@chebucto.ns.ca>
>To: <general@xml.apache.org>
>Sent: Friday, March 02, 2001 8:18 PM
>Subject: Mixing Two Terminologies


>Ted Leung, in his last post, sets out these steps (re-arranged somewhat):

>1. "If we build the right kind of community, developers will want to work
in it."

>2. "If developers want to work in it, they'll work out how to build great
software, and..."

>3. "...if they build great software, people will use it."

>I won't dispute the first point. I'll also grant the second point, assuming
>that we complete it with an earlier phrase from Ted's post: "The right kind
>of software will fall out of that [right kind of community]". Or more
>precisely, the right kind of community promotes the right kind of process,
>and the right kind of software is developed as a result of following the
>process. That latter phrasing is mine - I won't put words in Ted's mouth.

That's a good restatement of my intent in that section.  Let me expand that
a little by saying that I don't think that the community is only
code-hacking
developers.  There's room for people who want to help with documentation
testing and so forth.

>I'm not so sure about point 3. This is where I believe that Kimbro Staken's
>arguments are particularly on target - I don't think that developers, left
>to their own devices, are all that good at the boundary points. Namely,
>gathering input (requirements) and taking care of things after coding stops
>(the output). This is where management steps in - project management,
>program management and what have you. Which is primarily what I think all
>of this debate is ultimately about - how much of that do we want, and of
>what type?

To me part of the right kind of community is one where developers care
about requirements and crossing the T's and dotting the I's.   And I'd say
lets try to get that to happen from the bottom up in the sub-projects,
before
legislating it from on high via the PMC.

>I like and support the idea of working in a community where the people are
>supportive of each other, are here to have a good time, want to innovate,
>have the freedom to experiment and branch and abandon, and so forth. But I
>also try to remain cognizant of the fact that we are talking about software
>development here. We all know the rough figures - maybe 20-25% of a
>project's software development time ought to be spent on coding, an error
in
>requirements is several orders of magnitude more costly than an error in
>coding, 90% of a piece of software's life is spent in maintenance, etc etc.
>We ignore these factors at our peril if we want to make best use of our
>time, _and_ if we want to be truly professional about our efforts.

I'm not aware that any of the projects have a written requirements doc.  Ed
Staub and I tried to edit one for Xerces V2, but it wasn't what I'd call a
resounding success.   It is hard to gather requirements -- it's always a
squishy
business.  And frequently by the time the code is done, the requirements
have
changed.   Part of the beauty of these projects is that the developers get
to
interact with the users.  The development process is (or should be)
transparent
to users.  They can see what the bug fix list is, they can see what the
proposed
feature list is, and they can see what progress is being made.  The
developers get
exposed to a lot of requirements via the mailing lists.  I think that this
is good.
I wouldn't like to see the requirements go through some committee first.
In a
commercial software shop, it is important to understand your customers.
My experience is that developers rarely do.  At least part of that is
because
they never get to meet/interact with the customer. But we do that here all
the time.

To me, Open Source is much more about the process of software development.
The license is important, yes, but the community process is why this is
different
from doing this inside a single corporation.   And that's what I want to
protect.

>Or to address one point differently, what is "great" software (as mentioned
>in point 3)? I suggest that the finest piece of code in the world isn't
>close to being "great" until it includes documentation (design,
>requirements, testing, programmers, installation and operations), considers
>maintenance (or do we expect all our users to upgrade all the time?), and
>meets user needs (good testing).

My definition of great software includes documentation, maintainable code,
and real testing.  It has to be more than the code.

>Do we want to be professional in this sense? I know _I_ do. I try to do it
>at work, and sometimes it's frustrating. I'd like to be able to do that
>here. Ted mentioned not wanting to get burdened by business-related
>concerns. Well, I'll buy that. I'll go so far as to suggest that Apache
>might be just the place to experiment with _good_ product development,
which
>addresses users, rather than just software development, which is more
narrow
>but still keeps us A&D types involved, or just top-notch coding, which
>doubtless keeps a lot of people happy, but isn't the whole pie by a long
>shot. God knows it's hard to do in a lot of commercial shops, where TTM
>concerns preclude doing a lot of the stuff I just mentioned. We stand a
>decent chance of being able to show businesses how truly professional
>software development gets done. We are in an excellent position to do
>that. But only if folks think that's a priority. Not _the_ priority,
>but _a_ priority. Maybe I'm in a minority here. I don't know.

I agree with you.  Make it a minority of 2.

>Speaking from a FOP perspective, I personally get as much satisfaction from
>addressing a user bug report, or answering a spec question, or addressing a
>usage concern, as I do from hacking code. Ultimately, just getting feedback
>that our software helped solve a person's real-life problem. David Halsted
>mentioned ESR's reference to hackers deriving great satisfaction from
>seeing their code get used - I think that is a big motivating factor here,
>and we do (I think) want to consider how we can promote solutions, so as
>to increase adoption and user satisfaction. It would be nice to think that
>if we produce √úbercode that it will get recognized and adopted; real life
>shows us, I'm afraid, that marketing wins out 9 times out of 10. So I
believe
>that some kind of product strategy (however we label it) is not a bad idea.

I exaggerated  in my reply to Kimbro.  Nobody (including me) wants to write
code that doesn't get used.   I strongly believe that feedback from people
who
are actually using a product is the best way to understand their
requirements
and improve the product.  I've worked at companies where understanding
such feedback was the job of "marketing".  Unfortunately, those people
didn't
undestand the feedback, and those products were commercial failures.  I am
colored by those experiences.  I want to see the feedback.  All of it - good
and
bad - preferably more of the bad.  And I want the chance to engage in a
vigorous
debate with both my developer colleagues and my "customers" about what that
feedback really means.    I think that if you want to be successful at
building a
product, you need to really understand what your customer is trying to do,
why
(if he'll tell you) and how (if she'll tell you).   Then you figure out how
to take a
deep, accurate understanding and build a product that delights.  That's my
idea of product strategy.

Ted


Mime
View raw message