Re: re-use in physical simulations

In article <l5mVg.7849$TV3.7386@newssvr21.news.prodigy.com>, "Phlip"
<phlipcpp@yahoo.com> wrote:

!! galathaea wrote:
!!
!! > would an agile team
!! >  tasked with building a simulations system for an engineering firm
!! > consider it wise to consult past source of simulations
!! > perhaps requesting source usage priveleges?
!! >
!! > or is this unwise?
!!
!! Briefly, the system an "agile" team uses to research a domain is orthogon
al
!! to the team's agility. If the domain is physical simulations, then the te
am
!! should research pre-existing simulations. Nothing in the Agile literature
!! mandates this or precludes it.


is your position that an evaluation of reuse opportunities
is orthogonal to agility?
so where then is the separation?

what parts of process
are to be promoted for agility
and which processes
(even if assisting project completion)
are left open?

i think this is not clear in the literature at all

take xp as an example of such a process
as is core to general agility
the process is composed of self-similar iterations
this distributes the events that will occur
in this process
one should have daily standups to measure velocity
this describes how to spend a certain period time
and specific interactions that should occur
one should write tests to drive or challenge the authored code
this describes specific actions taken
for the purpose of completing the code

some of the literature does indeed make
connections of agility to a process of tool selection

see
java tools for eXtreme programming
or even jeffries own
extreme programming adventures in c#

!! However, two other important Agile notions are Communication and Courage.
!! Team members strive to write complete sentences that follow a familiar an
d
!! readable structure. And we practice behaving as if we are not afraid of o
ur
!! target domains - even when we are.


in my opinion
the interpretation of "communication" in xp
is one of its weakest positions

communications does not mean establishing formal coding guidelines
in the traditional form of identifierNamingConventions
and layout style guides

because coders should not be allowed
to become frozen and set in one such specification
if they are to debug into many 3rd party libraries
or reuse opensource
or work in multiple languages

if one wants to be
a capable and well-positioned software engineer
in the current turbulent industry
one cannot start getting a left-eyed twitch
every new coding style encountered

instead
i agree with alexandrescu and sutter's coding guideline

don't sweat the small stuff

stay consistent and clear
and focus more on content

communications should focus on the ontology of the software
through sharing an understanding of its layers and types
and should not be brought to a stop by a missing period

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
galathaea: prankster, fablist, magician, liar