[MUD-Dev] Architecture (Cell Rebalancing)

[J C Lawrence]

On Thu, 3 Jul 2003 02:43:55 +0200
Peter Rossmann <Peter> wrote:

> who is ISTR JC?

ISTR == I Seem To Recall

JC, or more often "JCL" or "Claw" would be me.

>> ...spoke a couple of times about dependent working sets on the night
>> before the MDC (in relation to a dicussion on geographical
>> partitioning).

> any links/memories of that speech? never heard that before.

Hit the list archives.  Its all there.  You might also like to dig back
to the old discussions around my server model and C&C (compare &
commit).  As base structure it wasn't a bad approach, and even scaled
fairly well for a soft-code runtime morphic system as long as
transaction set's working sets didn't cluster too hard.

>> Otherwise you have a design that is easy for a human to read on
>> paper, but practically impossible to implement.

> reading easines for human is only the visual/graphical
> configuration. if the design is right, then the partitioning will be
> right and the connections will be on proper places in regard to
> endpoints.

I've not jumped in on this design thread as you're approaching from an
angle which I know others find profitable, but which has never been
either useful or illuminating for me.  For me designs are best evolved
from constraints, requirements and use cases (which are really just
constraints married to requirements, but bear with me).

Start out by stating what you want to do.  Clearly, simply, in no more
than a half dozen nice declarative sentences.  Beat on that for a while
-- beat on it until nothing is left but the absolutely necessary major
bones.  This is your statement of "purpose".  Then work over that and
start pulling out some constraints and requirements.  Arm waving stuff
is good enough at this level.  Then go back and start adding use cases.
Start inventing scenarios.  Make then as detailed as you can.  Specify
WHAT the system must accomplish in the use cases, but not HOW.  This is
usually the fun bit -- don't hold back, thrown in everything you can
think of.

Now go back and line up your use cases with your purpose statement.  If
they fail to line up naturally, one or the other is at fault.  Fix it.
Once all the use cases are happy, pull in the requirements and
constraints to match.

Add more use cases.  Get dreamy.  Heck, add a use case every time you
get bored, have an idea, or just feel like it -- but make sure every one
lines up perfectly with the purpose statement (discard the ones that
head out on tangents).

Odds are you can get this done a few days to a week -- its normally a
lot of fun.  Once you've got that done you'll find you understand the
backgrounds and contexts that the basic design structures will start
natively falling out.

  A point to aware of here is that those design structures natively fall
  out so easily because there's a natural tendency to structure your
  thinking in terms of what you know.  Thus your use cases etc will tend
  to align to the types of systems, architectures, and models you're
  familiar with.

Now's the time to start the blue sky research.  Go dig. read (the
archives), find as many other fields of work and thought that you can
relate what you want to do to as you can.  Then cherry pick them, line
up your use cases, purpose statement etc, and get going.

> The trouble with many architects is that they start to program too
> soon, in too detailed areas and the result is no good then.

Yup.  The same is true of many architects: they design far too soon and
in too much abstraction.  Design is a Good Thing, but can kill a project
just as readily as lack of design.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
claw at kanga.nu               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev