EPP [was much longer]
Joseph Sinclair
plug-devel@lists.PLUG.phoenix.az.us
Fri Mar 11 20:58:03 2005
This is a multi-part message in MIME format.
--------------030607020403030109060302
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
I address your points in order below.
Trent Shipley wrote:
>Joseph, I was about to split this thread with a new subject of:
>"IFA project, PEP vision, and PEP working group"
>
>Of course I was really tempted to go for the title:
>"IFA project, PEP vision, and PEP squad"
>I had restrained myself, but without the discipline of a subject line I need
>not do so.
>
>* The Phoenix Event Planner working group are the associates of PLUG Devel who
>are working on PEP projects.
>
>* I see IFA as what we do *NEXT*. It is a proof-of-concept project. I tend
>to see it as a mini-project. The IFA project is not totally congruent with
>the overall PEP strategic vision. Nevertheless, the InstallFest problem
>seems to be a subset of the PEP domain and InstallFest has committed to being
>PEPs guinea pig, at least to the extent possible given InstallFest's loose
>organization.
>
>We still need to find out what our customer, InstallFest, wants from the PEP
>Working Group.
>
>* PEP has a strategic vision. It extends to a lot of potential consumers and
>many revisions over time. Because of a wide range of application and scale
>realizing PEP's strategic vision can be sketched as a timeline, but will
>require occasional changes in engineering and even architecture.
>
>There is still a lot of brainstorming to be done about PEP's strategic vision.
>
>On the other hand, because the viability of the project and it's group have
>yet to be demonstrated, system architects need to be a bit agnostic and quite
>sceptical about any strategic plans.
>
>
>
>
I'm uncomfortable with the firm/customer/project metaphor you're using,
as I don't believe it plays well to the Open Source development model.
One example of an open source system that started down that road is the
Avalon Project at Apache. They ended up closing down Avalon and taking
the 3 disparate "Projects" and setting 2 up as independent entities, and
merging the third into another project. There were a lot of things
behind this, but I think part of the reason was the diffusion of the
community that resulted from having multiple projects within a single
development community. We can (eventually, if we grow enough) have the
PLUG Devel act as a overarching structure (much like Apache, or even
Apache Jakarta) to multiple development communities, each gathered
around a single project, but I'd rather not try to have a single
development community trying to work on multiple projects.
>On Friday 2005-03-11 17:53, Joseph Sinclair wrote:
>
>
>>I never viewed the Installfest as the primary customer. They are
>>providing a convenient focus to the initial iterations, but I never
>>intended to create software specific to installfests, I think I
>>mentioned earlier that if that had been my preference, I would have
>>created something really simple.
>>
>>
>
>You are correct here.
>
>What I am advocating is treating InstallFest as a "real" customer with a real
>account. Similarly, we treat the PEP Working Group as a brand new firm. The
>viability of the firm has yet to be proven. A "really simple" little project
>is just perfect for our brand-new little software production firm.
>
>We build something, finish it, use it. In the process we build PEP and are
>ready for a somewhat bigger project. (Yes. This is a wedding of agility
>theory with capability-maturity organizational theory.)
>
>
>
I'd rather avoid a "proof of concept"(POC), simply because open source
is sustained by individual developers "scratching their itch", and a POC
doesn't provide that capability. There's no reason, we cannot simply
begin building the full-out system up front. Here are a few reasons why
I feel more comfortable doing just that:
a) We don't have an imposed deadline, we set our own deadlines, so
community shakeout won't hurt anyone.
b) We don't have a market imperative, so being "close" in terms of
meeting needs is fine. As people are attracted to the system, they'll
provide the vital customer input for future revisions. Until then,
there's nothing wrong with writing some of the story cards ourselves. I
know that's not quite XP, but then neither are we running this as strict XP.
c) I have no intention of sacrificing the needs of the installfest, I
just don't intend to use them as a limit in any way either.
d) In any open source or lightweight project, architecture evolves
with the system. The key is to choose a platform that can support the
required evolution. If the needs of the system (or technology) ever
become such that the platform is no longer viable, then the project
needs to evaluate how to reimplement on a new platform (much as the
Xerces parser from Apache did in moving from C++ to Java).
e) Open source relies on generating excitement and interest in a wide
community. The installfest community is far too small for that, so we
need to target, as soon as possible, the larger event planning
community. To do this, we need to have something that is usable by that
wider community (although far from feature complete) within a relatively
short timeframe after project start. That's why I asked for a 6-month
commitment from initial volunteers. That gives us enough time to create
software that has enough utility to attract a wider community to
continue the development.
>>I've been working with lightweight methodologies, primarily XP, for
>>around 5 years now, and I have never been able to find in the XP
>>methodology anything that suggests you build your system as though the
>>current iteration is the entire system. You don't build *functionality*
>>not needed by the current iteration, but you do build this iteration's
>>functionality with the understanding of the entire release, and you make
>>architectural and design decisions with the entire project vision in mind.
>>
>>
>
>I keep thinking of (ASU Software factory's) Steve Gordon's hatered of software
>"requirements".
>
>
>
Steve worked for me on one of my first XP projects, and the first one
where I led the team. We share a disgust with formal software
requirements. I think we both find user stories to be pretty close to
exactly what's needed for a fast-moving and lightweight development model.
>As a software shop, the PEP Squad can work with InstallFest to build solutions
>for InstallFest. That is concrete.
>
>
The people working this project (nobody's agreed to PEP yet, I actually
prefer EPP, for Event Planning Project, until the community is large
enough to select a formal name) are not a software shop. They're
volunteers in an open source project. The project sponsoring group
(sort of) is PLUG.
>The problem I have is not that there should be a strategic vision beyond IFA
>and corresponding architectural plans, it is that architecture needs to be
>based on so many highly speculative functions ... it all amounts to
>theoretical business theory. I would feel MUCH more comfortable working off
>a larger architectural plan if I knew the plan was based not in theory but in
>grounded research.
>
>
The point of using lightweight development is to compensate for the fact
that we
a) don't know a lot of things about what the user community needs are
b) don't have the resources to perform grounded research in this area
c) are staffed by volunteers, not employees.
>For example later on you will turn Bryan's hypothesized need for unconnected
>workstation operation into a user story. Unfortunately, it is only an
>*imagined* user story. I would be MUCH happier if it were not an imagined
>story, but based on utterances elicited from a potential consumer or analyst
>participant observation.
>
>At this point, of course, my opinion is based on too much education and too
>little experience.
>
>My concern is that coding to a strategic architecture at this point is
>premature. Right now a strategic architecture must be based on poorly
>grounded assumptions about consumers and markets. To do more architecture we
>should have more real customers and more real research.
>
><important>
>As junior to senior, I want an explanation about why we have enough
>information to GENERALIZE the architecture WELL beyond the IFA account to the
>PLUG/AZOTO account (that I did not know existed until now) and beyond.
></important>
>
>
PLUG is the organization "sponsoring" this open source project. AZOTO
is Hans' vision for a larger open technology umbrella organization. We
have the entire membership and leadership of both organizations
available to express whatever needs they have WRT event planning. Why
not take advantage of that and build to the larger vision?
>
>
>>I think these three things start to bring light to this discussion,
>>Trent. You are trying to see the "best" (i.e.
>>simplest/cheapest/easiest) way to build an installfest application, with
>>the installfest as a primary customer,
>>
>>
>
>Check. Although that is short term (2 quarters at most) and tactical.
>
>
>
>>and a strong desire to place the
>>final solution in GNUe.
>>
>>
>
>I am not married to GNUe. In the short term, I do not even care about it.
>
>I DO think that given what I see as PEP's strategic potential, that PEP would
>gain synergy by being a module in a FOSS ERP/M solution (and GNUe is the only
>one I know about).
>
>
>
I don't see a lot of value in integrating event planning with ERP/ERM,
event planning (IME) is sufficiently distant from resource planning, and
it's fundamental requirements are sufficiently hostile to those of
resource planning, that I actually see integrating with ERP to be a "bad
thing". GNUe is a broader enterprise framework, and if the majority (at
least 3) of core developer volunteers are Python coders (since AFAIK
GNUe forces Python as the language choice) then that's a platform
option. J2EE is another enterprise framework that's been suggested, and
the same metric applies to it's possible selection. Mono is yet another
framework, with the same options available. There are several other
such frameworks, the choice will depend on the people who volunteer to
do the work. I don't particularly care about possible synergies, since
ALL of the platforms I know of will gain benefits from the existing
community of solutions built with those frameworks.
>>I am trying to see the "best" way to build a
>>full-out enterprise event planning and management system with PLUG/AZOTO
>>as the primary customer (much broader needs there), the installfest as a
>>nice proxy customer for a few iterations,
>>
>>
>
>Like I said, I know nothing about the PLUG/AZOTO account. In business terms,
>I may not NEED to know more about this account, but I think I SHOULD know
>more about it.
>
>Also I am thinking more concretely in terms of customer+architecture as A
>project instead of an overall strategic vision and a grand architecture.
>
><important point>
>
>So Trent's working methodology:
>
>* strategic vision = full-out enterprise event planning and management system
>in an ERP/M context
>** Strategic vision will be changing all the time. Resistant to architecture
>** Stratigic vision will be realized over time through many projects.
>** Projects are informed by overall vision.
>
>* Customer = Project
>** project has interations.
>** Customers must be treated like customers. Each gets best eXP service
>available even if that is not maximizing for the strategic vision.
>
>Joseph's working methodology.
>
>* strategic vision = full-out enterprise event planning and management system
>** Insure high quality, maintainable software by creating architecture NOW!
>
>
Actually, just create the overall vision now, and select an appropriate
platform. The architecture will evolve over time(the Pad method [BigP,
smallA, miniD]).
>** Stratigic vision will be realized over time through many interations.
>** Iteration = customer
>
>
Iteration == a small block of useful functionality
Customer == a large community that will (I REALLY REALLY REALLY hope)
grow and evolve over time
></important point>
>
>Of course, if we have two accounts, and do neither an injustice by sharing
>resources between them, then we should do that.
>
>Nevertheless, This means that the PEP Squad software shop has two distinct (if
>friendly) customers. It would be unethical to sacrifice InstallFest to
>PLUG/AZOTO.
>
>
Installfest is a subgroup within PLUG/AZOTO which is one entity within
the event planning community, and as such there is no conflict in
crafting the vision for the event planning community, the first release
plan for AZOTO, and the first(few) iteration plan(s) for installfest.
>
>
>>a strong desire to see the
>>software built using the platform preferred by those willing to
>>volunteer as core developers,
>>
>>
>
>Fair enough. You cannot build software without developers and
>para-developers.
>
>
>
>>and a desire to ensure it actually gets
>>built, whether I like the final PAD(Platform/Architecture/Design) or
>>not.
>>
>>
>
>YESSS. Building something deliverable GOOD. Very GOOOOD.
>
>
Remember, iteration results do something useful, they are generally NOT
deliverable. Releases are deliverable. The point of iterations is to
have a completed base from which anyone(the original team, or any
replacement thereof) can pick up the development and finish a release,
should the need and will exist to do so.
>
>
> <<SNIP>>
>
>>Since it's utterly insane to expect an unsophisticated user (i.e. church
>>admin, "soccer mom", etc...) to install the LAMP components (or GNUe or
>>J2EE) on their workstation,
>>
>>
>
>Could not these be built to "auto-install" in a default configuration?
>
>
90%+ of non-technologist users cannot do so. LAMP DOES NOT auto-install
into a form that could be used for the planned system (especially the
Linux and MySQL portions). Besides, that's carrying a HUGE overhead on
the client(network services, enterprise database[MySQL], a whole new
O/S, etc...) just to run an application that doesn't in any way actually
need any of those services.
>>I would expect the single-user solution to
>>be an easily downloadable (PDM, Java WebStart, etc...) client
>>application capable of running in both online and offline modes, and
>>with the option to have no parent server at all.
>>
>>
>
>I am unfamiliar with these technologies. Are we basically talking about a
>"fat client"; that is, an application on the user's console?
>
>
PDM is a Python (and no I don't know where to find it, I just
encountered it 2 jobs back) technology for automatic download of a local
application. WebStart is the Java technology that allows a Java
application to be downloaded initially from a website, but run as a
local application. A WebStart or PDM application will automatically
update it's components if the system is online when the application is
launched, and there are any newer modules available at the original
source URI. I understand that there are similar technologies available
for .Net/Mono, C++, and other development platforms/languages.
Yes, I'm talking about a fat client on the user's system, with some
enhancements to distribution and update. The client would have some
level of interaction with the enterprise system available, but not
required. This type of client would also be used for PDA clients, so
event information could be entered in the system on the go, and uploaded
into the enterprise system the next time the unit connected to the server.
<<SNIP>>
--------------030607020403030109060302
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I address your points in order below.<br>
<br>
Trent Shipley wrote:
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<pre wrap="">Joseph, I was about to split this thread with a new subject of:
"IFA project, PEP vision, and PEP working group"
Of course I was really tempted to go for the title:
"IFA project, PEP vision, and PEP squad"
I had restrained myself, but without the discipline of a subject line I need
not do so.
* The Phoenix Event Planner working group are the associates of PLUG Devel who
are working on PEP projects.
* I see IFA as what we do *NEXT*. It is a proof-of-concept project. I tend
to see it as a mini-project. The IFA project is not totally congruent with
the overall PEP strategic vision. Nevertheless, the InstallFest problem
seems to be a subset of the PEP domain and InstallFest has committed to being
PEPs guinea pig, at least to the extent possible given InstallFest's loose
organization.
We still need to find out what our customer, InstallFest, wants from the PEP
Working Group.
* PEP has a strategic vision. It extends to a lot of potential consumers and
many revisions over time. Because of a wide range of application and scale
realizing PEP's strategic vision can be sketched as a timeline, but will
require occasional changes in engineering and even architecture.
There is still a lot of brainstorming to be done about PEP's strategic vision.
On the other hand, because the viability of the project and it's group have
yet to be demonstrated, system architects need to be a bit agnostic and quite
sceptical about any strategic plans.
</pre>
</blockquote>
I'm uncomfortable with the firm/customer/project metaphor you're
using, as I don't believe it plays well to the Open Source development
model. One example of an open source system that started down that
road is the Avalon Project at Apache. They ended up closing down
Avalon and taking the 3 disparate "Projects" and setting 2 up as
independent entities, and merging the third into another project.
There were a lot of things behind this, but I think part of the reason
was the diffusion of the community that resulted from having multiple
projects within a single development community. We can (eventually, if
we grow enough) have the PLUG Devel act as a overarching structure
(much like Apache, or even Apache Jakarta) to multiple development
communities, each gathered around a single project, but I'd rather not
try to have a single development community trying to work on multiple
projects.<br>
<br>
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<pre wrap="">On Friday 2005-03-11 17:53, Joseph Sinclair wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I never viewed the Installfest as the primary customer. They are
providing a convenient focus to the initial iterations, but I never
intended to create software specific to installfests, I think I
mentioned earlier that if that had been my preference, I would have
created something really simple.
</pre>
</blockquote>
<pre wrap=""><!---->
You are correct here.
What I am advocating is treating InstallFest as a "real" customer with a real
account. Similarly, we treat the PEP Working Group as a brand new firm. The
viability of the firm has yet to be proven. A "really simple" little project
is just perfect for our brand-new little software production firm.
We build something, finish it, use it. In the process we build PEP and are
ready for a somewhat bigger project. (Yes. This is a wedding of agility
theory with capability-maturity organizational theory.)
</pre>
</blockquote>
I'd rather avoid a "proof of concept"(POC), simply because open
source is sustained by individual developers "scratching their itch",
and a POC doesn't provide that capability. There's no reason, we
cannot
simply begin building the full-out system up front. Here are a few
reasons why I feel more comfortable doing just that:<br>
a) We don't have an imposed deadline, we set our own deadlines, so
community shakeout won't hurt anyone.<br>
b) We don't have a market imperative, so being "close" in terms of
meeting needs is fine. As people are attracted to the system, they'll
provide the vital customer input for future revisions. Until then,
there's nothing wrong with writing some of the story cards ourselves.
I know that's not quite XP, but then neither are we running this as
strict XP.<br>
c) I have no intention of sacrificing the needs of the installfest, I
just don't intend to use them as a limit in any way either.<br>
d) In any open source or lightweight project, architecture evolves
with the system. The key is to choose a platform that can support the
required evolution. If the needs of the system (or technology) ever
become such that the platform is no longer viable, then the project
needs to evaluate how to reimplement on a new platform (much as the
Xerces parser from Apache did in moving from C++ to Java).<br>
e) Open source relies on generating excitement and interest in a wide
community. The installfest community is far too small for that, so we
need to target, as soon as possible, the larger event planning
community. To do this, we need to have something that is usable by
that wider community (although far from feature complete) within a
relatively short timeframe after project start. That's why I asked for
a 6-month commitment from initial volunteers. That gives us enough
time to create software that has enough utility to attract a wider
community to continue the development.<br>
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">I've been working with lightweight methodologies, primarily XP, for
around 5 years now, and I have never been able to find in the XP
methodology anything that suggests you build your system as though the
current iteration is the entire system. You don't build *functionality*
not needed by the current iteration, but you do build this iteration's
functionality with the understanding of the entire release, and you make
architectural and design decisions with the entire project vision in mind.
</pre>
</blockquote>
<pre wrap=""><!---->
I keep thinking of (ASU Software factory's) Steve Gordon's hatered of software
"requirements".
</pre>
</blockquote>
Steve worked for me on one of my first XP projects, and the first
one where I led the team. We share a disgust with formal software
requirements. I think we both find user stories to be pretty close to
exactly what's needed for a fast-moving and lightweight development
model.<br>
<br>
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<pre wrap="">As a software shop, the PEP Squad can work with InstallFest to build solutions
for InstallFest. That is concrete.
</pre>
</blockquote>
The people working this project (nobody's agreed to PEP yet, I actually
prefer EPP, for Event Planning Project, until the community is large
enough to select a formal name) are not a software shop. They're
volunteers in an open source project. The project sponsoring group
(sort of) is PLUG.<br>
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<pre wrap="">
The problem I have is not that there should be a strategic vision beyond IFA
and corresponding architectural plans, it is that architecture needs to be
based on so many highly speculative functions ... it all amounts to
theoretical business theory. I would feel MUCH more comfortable working off
a larger architectural plan if I knew the plan was based not in theory but in
grounded research.
</pre>
</blockquote>
The point of using lightweight development is to compensate for the
fact that we<br>
a) don't know a lot of things about what the user community needs are<br>
b) don't have the resources to perform grounded research in this area<br>
c) are staffed by volunteers, not employees.<br>
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<pre wrap="">
For example later on you will turn Bryan's hypothesized need for unconnected
workstation operation into a user story. Unfortunately, it is only an
*imagined* user story. I would be MUCH happier if it were not an imagined
story, but based on utterances elicited from a potential consumer or analyst
participant observation.
At this point, of course, my opinion is based on too much education and too
little experience.
My concern is that coding to a strategic architecture at this point is
premature. Right now a strategic architecture must be based on poorly
grounded assumptions about consumers and markets. To do more architecture we
should have more real customers and more real research.
<important>
As junior to senior, I want an explanation about why we have enough
information to GENERALIZE the architecture WELL beyond the IFA account to the
PLUG/AZOTO account (that I did not know existed until now) and beyond.
</important>
</pre>
</blockquote>
PLUG is the organization "sponsoring" this open source project. AZOTO
is Hans' vision for a larger open technology umbrella organization. We
have the entire membership and leadership of both organizations
available to express whatever needs they have WRT event planning. Why
not take advantage of that and build to the larger vision?<br>
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">I think these three things start to bring light to this discussion,
Trent. You are trying to see the "best" (i.e.
simplest/cheapest/easiest) way to build an installfest application, with
the installfest as a primary customer,
</pre>
</blockquote>
<pre wrap=""><!---->
Check. Although that is short term (2 quarters at most) and tactical.
</pre>
<blockquote type="cite">
<pre wrap="">and a strong desire to place the
final solution in GNUe.
</pre>
</blockquote>
<pre wrap=""><!---->
I am not married to GNUe. In the short term, I do not even care about it.
I DO think that given what I see as PEP's strategic potential, that PEP would
gain synergy by being a module in a FOSS ERP/M solution (and GNUe is the only
one I know about).
</pre>
</blockquote>
I don't see a lot of value in integrating event planning with ERP/ERM,
event planning (IME) is sufficiently distant from resource planning,
and it's fundamental requirements are sufficiently hostile to those of
resource planning, that I actually see integrating with ERP to be a
"bad thing". GNUe is a broader enterprise framework, and if the
majority (at least 3) of core developer volunteers are Python coders
(since AFAIK GNUe forces Python as the language choice) then that's a
platform option. J2EE is another enterprise framework that's been
suggested, and the same metric applies to it's possible selection.
Mono is yet another framework, with the same options available. There
are several other such frameworks, the choice will depend on the people
who volunteer to do the work. I don't particularly care about possible
synergies, since ALL of the platforms I know of will gain benefits from
the existing community of solutions built with those frameworks.<br>
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">I am trying to see the "best" way to build a
full-out enterprise event planning and management system with PLUG/AZOTO
as the primary customer (much broader needs there), the installfest as a
nice proxy customer for a few iterations,
</pre>
</blockquote>
<pre wrap=""><!---->
Like I said, I know nothing about the PLUG/AZOTO account. In business terms,
I may not NEED to know more about this account, but I think I SHOULD know
more about it.
Also I am thinking more concretely in terms of customer+architecture as A
project instead of an overall strategic vision and a grand architecture.
<important point>
So Trent's working methodology:
* strategic vision = full-out enterprise event planning and management system
in an ERP/M context
** Strategic vision will be changing all the time. Resistant to architecture
** Stratigic vision will be realized over time through many projects.
** Projects are informed by overall vision.
* Customer = Project
** project has interations.
** Customers must be treated like customers. Each gets best eXP service
available even if that is not maximizing for the strategic vision.
Joseph's working methodology.
* strategic vision = full-out enterprise event planning and management system
** Insure high quality, maintainable software by creating architecture NOW!
</pre>
</blockquote>
Actually, just create the overall vision now, and select an appropriate
platform. The architecture will evolve over time(the Pa<small>d<big>
method [BigP, smallA, miniD]).</big></small><br>
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<pre wrap="">** Stratigic vision will be realized over time through many interations.
** Iteration = customer
</pre>
</blockquote>
Iteration == a small block of useful functionality<br>
Customer == a large community that will (I REALLY REALLY REALLY hope)
grow and evolve over time<br>
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<pre wrap="">
</important point>
Of course, if we have two accounts, and do neither an injustice by sharing
resources between them, then we should do that.
Nevertheless, This means that the PEP Squad software shop has two distinct (if
friendly) customers. It would be unethical to sacrifice InstallFest to
PLUG/AZOTO.
</pre>
</blockquote>
Installfest is a subgroup within PLUG/AZOTO which is one entity within
the event planning community, and as such there is no conflict in
crafting the vision for the event planning community, the first release
plan for AZOTO, and the first(few) iteration plan(s) for installfest.<br>
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">a strong desire to see the
software built using the platform preferred by those willing to
volunteer as core developers,
</pre>
</blockquote>
<pre wrap=""><!---->
Fair enough. You cannot build software without developers and
para-developers.
</pre>
<blockquote type="cite">
<pre wrap="">and a desire to ensure it actually gets
built, whether I like the final PAD(Platform/Architecture/Design) or
not.
</pre>
</blockquote>
<pre wrap=""><!---->
YESSS. Building something deliverable GOOD. Very GOOOOD.
</pre>
</blockquote>
Remember, iteration results do something useful, they are generally NOT
deliverable. Releases are deliverable. The point of iterations is to
have a completed base from which anyone(the original team, or any
replacement thereof) can pick up the development and finish a release,
should the need and will exist to do so.<br>
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<pre wrap="">
</pre>
<<SNIP>><br>
<blockquote type="cite">
<pre wrap="">Since it's utterly insane to expect an unsophisticated user (i.e. church
admin, "soccer mom", etc...) to install the LAMP components (or GNUe or
J2EE) on their workstation,
</pre>
</blockquote>
<pre wrap=""><!---->
Could not these be built to "auto-install" in a default configuration?
</pre>
</blockquote>
90%+ of non-technologist users cannot do so. LAMP <big><big><small><small>DOES
NOT auto-install into a form that could be used for the planned system
(especially the Linux and MySQL portions). Besides, that's carrying a
HUGE overhead on the client(network services, enterprise
database[MySQL], a whole new O/S, etc...) just to run an application
that doesn't in any way actually need any of those services.</small></small></big></big><br>
<blockquote cite="mid200503111925.18499.tshipley@deru.com" type="cite">
<blockquote type="cite">
<pre wrap="">I would expect the single-user solution to
be an easily downloadable (PDM, Java WebStart, etc...) client
application capable of running in both online and offline modes, and
with the option to have no parent server at all.
</pre>
</blockquote>
<pre wrap=""><!---->
I am unfamiliar with these technologies. Are we basically talking about a
"fat client"; that is, an application on the user's console?
</pre>
</blockquote>
PDM is a Python (and no I don't know where to find it, I just
encountered it 2 jobs back) technology for automatic download of a
local application. WebStart is the Java technology that allows a Java
application to be downloaded initially from a website, but run as a
local application. A WebStart or PDM application will automatically
update it's components if the system is online when the application is
launched, and there are any newer modules available at the original
source URI. I understand that there are similar technologies available
for .Net/Mono, C++, and other development platforms/languages.<br>
<br>
Yes, I'm talking about a fat client on the user's system, with some
enhancements to distribution and update. The client would have some
level of interaction with the enterprise system available, but not
required. This type of client would also be used for PDA clients, so
event information could be entered in the system on the go, and
uploaded into the enterprise system the next time the unit connected to
the server.<br>
<br>
<br>
<<SNIP>><br>
<br>
<br>
</body>
</html>
--------------030607020403030109060302--