RE: Is "simplicity" a useful architectural constraint?

> I agree with Roy.  I find Java to be pretty useful and it has 
> a rather large
> set of specifications around it.  I also find reliable 
> messaging systems to
> be pretty useful, and they have fairly large specifications as well.

I like Java, too, but how many people are familiar with all the pertinent
Java package classes associated with the problem-of-the-moment? (Why, for
example, was Tree in one of the UI packages [version 1.1]?). The scope of
packages adds to the complexity of understanding how to effectively use
them. MFC is worse, mind you, in terms of its design (and I have not
personally delved into .NET, but OMG). Size does affect complexity, but
yeah, it's not the only measure.

> I still can't write an XML 
> schema document
> with refinement and facet constraints without referring to 
> the primer, yet I
> can easily write subclasses in Java.  

But can you write an accurage clone() method? :-) Well, maybe *you* can...

> A final point is that sometimes you just can't make the spec 
> simple as the
> task is just too complicated.

I have a saying:

	For every complicated problem, there are a bunch of simpler problems
screaming to get out.

If the task is that monolithic, break it up and address bits of it at a
time. I think there's a lot of specs that address too much at once, due to
the geek desire to be 'complete'. I say to heck with complete: give us
something simple first, then layer complexity on top of it. There's people
screaming for XQUERY update support right now, but is everyone who uses
XQUERY going to do updates? (BTW, where in the definition of 'query' does
the term 'update' show up?)

Uh, oh... I've entered the Ranting Zone. Do-do do-do, do-do do-do...


> To me, the trade-off is really about picking the complexity in the the
> audience size versus functionality chart that best meets the 
> goals of the
> spec.  Kind of like the innovation point on the chaos versus 
> order chart.

???

Received on Thursday, 3 January 2002 13:39:00 UTC