[extropy-chat] Some ideas... dumped

[Samantha Atkins]

On Aug 13, 2004, at 10:55 PM, Emlyn wrote:

> I'll expound shortly on a half baked software development methodology
> that I've got brewing in my head, tentatively tagged "disposable
> code". The axioms are "assume you start with a few spectacular coders,
> genius hackers, who can kind of work together, are individually
> irreplaceable, and most of whom don't like working with each other.
> What can you do?". It's a reaction to the regular methodologies
> (standard big system & agile) which assume that you want to work with
> endless fields of stupified code grinders, and that the brilliant
> cowboys in the corner are a liability...
>

Perhaps I missed it but I saw nothing in a quick exploration of agile 
methodologies that implies that brilliant hackers are a liability.    
Please point out what you mean.  Perhaps this perception is more of a 
question of management considering these folks liabilities than the 
methodology considering them thus.


> I think it will combines with an idea I blogged in July called "Object
> Bus" (dumb name), which is that you create a layer above messaging and
> databases onto which you can put objects, from which you can retrieve
> objects, including message sending style behaviour and database style
> behaviour. The "space" of objects is above the machine level (many
> machines can be involved, transparently). This way you can write lots
> of little programs that just do a bit of something, interacting only
> with the "object bus" and not with each other directly. From what
> little I know of Java, this is a bit like Java spaces, but the
> difference is that it is non language specific, meant to be dead easy
> to use, and applicable to desktop apps as well as big enterprise
> craziness. I wonder if a P2P approach under the covers could work
> here? This goes on and on, see the July archive in my blog for more
> detail.

Sounds something like the "cloud of objects" notion from the 80s.  
There was a lot of rich thinking about OO systems, languages and 
methodologies back then that has mainly been ignored in the "real 
world" since.  I've coded things roughly like this many times.   Mostly 
management and most coders and most software business models don't get 
it.  It is usually an uphill fight.   Often you end up needing to nail 
down something to build the object cloud on top of.  Like there usually 
is an underlying persistent model that has many alternate mappings to 
different kinds of database implementation.  There is an underlying 
rock-bottom set of messaging assumptions that there may be different 
implementations of.  Usually there is a lowest level communication 
method  with which to coordinate the rest.

> - samantha