Help for my manager, resend

[EVERETT813 at aol.com]

Well, it seems that my reply is going into a black hole somewhere.   Anyway, 
Harrison kindly alerted me that such was the case.   Below is my original 
post, and an addendum that I thought of later.

Paul Everett

Harrison wrote:

> He knows all about playing by the old rules which require a project plan,
> budget, staffing levels, milestones, evaluation and testing procedure, and
> all the rest. But, what about all this "self-organizing" stuff? How do you
> play by the new rules? What are they? And last but not least - how do you
> rationalize what you have done under the new rules so that it looks like the
> "old rules" have been observed? This last part may seem sneaky and
> dishonest, but my young manager friend really likes his job.
> 
> 
Harrison,

Well, I'm not sure this is probable (it may be slightly possible).  As Kuhn 
writes, the user of a new paradigm hasn't got the proof that it is the way to 
go.  Everything says otherwise.  The risk takers are going on 'faith' in their 
instincts.  Your young manager has more than that, he has deep world 
experience with OS to draw on.  Maybe he can use it to get an "aha" about the 
programming process itself.

But, about the self-organizing to write a new software program, that seems 
really iffy.  Software requires strategy, discipline and right code, not 
something that very easily emerges from no structure.  Even Chaos, with it's 
structure of bounded instability, can't predict what the outcome will be or when it 
will emerge.  Only that something will.  Rather like the instructions for 
building an ant's nest.

1.  When an ant, carrying a stick, comes to another stick, the ant puts its 
stick down.

2.  When an ant, not carrying a stick, comes to a stick, it picks the stick 
up.

Those two instructions will build an ant hill (mathematically, I'm told) but 
you can't tell where or when it will emerge, just that it will.  I doubt this 
will be sufficient for the client. 

Maybe the two process should be separated.  The 'chaos' of OS for 
breakthroughs, the discipline of code writing for getting something needed to emerge in a 
timely, semi-predictable manner to meet the needs of the client customer. 

Paul Everett

Addendum:   As I read the other comments, I realized I had said much the same 
thing---except maybe not so elegantly.  That is, separate the code writing 
from the issue of how and what to write, which one writer suggested.  I think 
the real task is to get into a solidly creative state, meaning one in which 
there is an absence of rejection of any known kind.  OS certainly does help that, 
but doesn't assure it, in my mind.  The only way I'm aware of ensuring it is 
to make that state of mind explicit and keep it in front of people's 
consciousness.  Suspension of judgment is another part of that state of mind.  All that 
judgment stuff comes later, when decisions must be made (convergence). 


*
*
==========================================================
OSLIST at LISTSERV.BOISESTATE.EDU
------------------------------
To subscribe, unsubscribe, change your options,
view the archives of oslist at listserv.boisestate.edu:
http://listserv.boisestate.edu/archives/oslist.html

To learn about OpenSpaceEmailLists and OSLIST FAQs:
http://www.openspaceworld.org/oslist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openspacetech.org/pipermail/oslist-openspacetech.org/attachments/20050221/f9ef35a9/attachment-0015.htm>