[JDEV] Process

[Eric Bowersox]

Kudos, Flint!  Bravo!  This articulates a LOT of what I've been trying to
tell people here while we have these incessant meetings on "defining a
process" for development.

I would say more, but I tend to start ranting when I think too much about
this subject.

					Eric

> -----Original Message-----
> From: Flint Hoskins [mailto:FHoskins at jabber.com]
> Sent: Thursday, September 07, 2000 8:40 AM
> To: 'jdev at jabber.org'
> Subject: [JDEV] Process
> 
> 
> Process
> 
> Why do we want a process?
> 
> 	This is where one must realize that process is multi 
> dimensional. 
>  
> Programmers are usually heranged to describe their process.  
> Which is an
> attempt to imitate the mental process with something that is 
> described in
> words and generates documents.  While laudible, no process 
> can imitate the
> human mind.
> Individuals outside of the programming loop want a process, 
> so they have
> points of interaction.  Places where there feedback can be 
> introduced and
> there timing considerations can be voiced and imposed on the 
> process.  After
> all, if you left everything up to programmers, they might 
> just create killer
> games all the time.
> Interested individuals want a process so they can spy on 
> productivity.  When
> is the rewrite going to be done? When is this cool feature 
> going to be out?
> Is anyone working on this feature? Can I get into this process? Can I
> document the process and demonstrate culpability to clients?  
> Can I change
> the programs behaviour to do what I want it to do? ...
> Why do we resist process?
> 	
> 	Process introduces overhead, creates interruptions, and exposes
> individuals to needs beyond their own current concerns.
> 
> Many projects have been ruined by process, and no project is 
> ever created by
> process alone.
> Archiving is one of the first goals.  
> 	Everyone has their own idea about what is useful documentation.
> 
> Programmers want enough documentation, mostly in the code and 
> possibly a few
> README files, to provide hints in case they want to revisit 
> some code they
> have already written.  If you have the dubious privilege of inheriting
> someone elses project ... suddenly you wish there was much more
> documentation.  In most cases you don't want to learn the whole coding
> paradigm that was used to create this 'wonderful' project, 
> you probably just
> want to get in and get out.  After all, no one programs as 
> well as you do,
> so you're anticipating the set of 'why did they do it that way?'.
> Users want feature documentation ... what does the product 
> do? How do I
> interact with it?
> Prototyping is one of the misunderstood creatures.
> 	Someone heavily tied to a software lifecycle, is likely 
> to be quite
> miffed by the ad-hoc creativity of prototypes.
> 
> 	What does it do?  I'm not sure yet, but it's cool.
> Timing is well misplaced.
> 	A project can only be accurately documented after the fact.
> 
> 	Initial design is just a phase to kickstart the project 
> and provide
> steering, design should always be conducive to revisitation.
> 	Deadends are just that and should be pulled out  or 
> identified as
> such.
> Can we do without process?
> 	Where there is activity, there is process.  
> 
> It is just a matter of identifying cost vs benefit.
> But, a process will give us ...
> 	Identifying the fruits desired must be the goal of process
> definition.
> 
> 	Programmers want a productive environment.
> 	Projects want a productive project.
> Freedom should be you're torch.
> 	Open source is flourishing because it embraces freedom.
> 
> 	Freedom to create what you want.
> 	Freedom to create what you need.
> 	Freedom to share it with others.