xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arved Sandstrom <Arved...@chebucto.ns.ca>
Subject Mixing Two Terminologies
Date Sat, 03 Mar 2001 04:18:59 GMT
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.

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?

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.

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

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.

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.

Just some rambling thoughts.

Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia

View raw message