Re: Is "simplicity" a useful architectural constraint?

There is no correspondence between good protocols and simple specification.

There are some protocols that are simple to describe but, as a result,
cause the number of interactions necessary to do anything via those protocols
to be very complex.  There are other protocols that are difficult to describe
due to the number of potential states, but are simple in practice because
the state machine to implement them is relatively flat.  There are many
specifications that are simply incomplete, and other specifications that
are long because the wrong formalism was chosen.  Likewise, many protocols
have been designed with layers for "simplicity", only to find that those
layers cause so much overhead, alignment, and fragmentation problems that
an efficient implementation becomes hopelessly complex.

I've never seen a good formal notation that was shorter than a specification
without formalism.  One is not a substitute for the other.  I once wrote a
95 page Z specification of a boulevard stop -- the same protocol is described
in two pages in the California driver's manual.  Likewise, formalisms are
notoriously bad for describing the workarounds necessary to deal with
poor implementations.

Ignore the size of the specification.  What is important in an architecture
is the complexity of an implementation and the complexity of its interactions
with other components.


Received on Wednesday, 2 January 2002 20:52:09 UTC