Re: [Endymail] We're not done yet

[Dave Crocker <[e-mail]>]

On 11/18/2014 1:43 AM, Stephen Farrell wrote:
> 
> 
> On 18/11/14 05:11, Watson Ladd wrote:
>> Do architecture and requirements documents actually work? Or do they
>> end up overcomplicating solutions, 
...
> I know Dave Crocker has done some work in this space (and he's
> the author of RFC5598 as well) - so Dave, do you think there'd
> be value in an RFC along those lines describing an architecture
> for a modern secure interpersonal messaging system that could
> scale and supports implementations with privacy friendly
> features? 



Whether it's code, protocol specifications, architecture or
requirements, whatever is written requires serious discipline and
careful attention to utility -- that is, to being useful.  Each of these
has a long history of examples of impracticality, bloat, and/or
silliness.  (The worst piece of code I've ever seen what written in a
highly structure-oriented language; the prettiest piece of code was
written in assembler.  So code is as subject to abuse as architecture
documents.)

Requirements docs tend to suffer from failures to distinguish between
what really is essential, versus what is merely desired. (Hence, almost
all the IETF documents that call themselves 'requirements' should be
re-labeled, IMO.)

Architecture defines components, objects and the relationships among
them.  Good architecture docs clarify things well and guide further work.

Architecture exists whether we document or not.  The difference is that
when it is documented, we have a better chance of sharing the same
understanding of it, and therefore meaning the same thing as we discuss
things.  (As a consequence, good architecture docs often allows
debugging issues prior to the work of coding.)

Quite a bit of discussion on this list has been about architecture, when
it hasn't debated specific algorithms.  But I'm unclear what goals are
being agreed to or met or how decisions being made satisfy them.
Documenting the architecture doesn't answer such questions, but it
provides a useful place for reviewing whether the decisions match and
satisfy the goals.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net