RE: Is "simplicity" a useful architectural constraint?

Simplicity should be a goal, but not the only one. Solving the problem at
hand has to be the primary goal. Someone famous (I can't remember who right
now) once said that things should be a simple as possible, but no simpler.

As that applies to the Web I think this means that the specs must be as
complex as necessary to solve the stated problems, but not more complex.
"The simplest solution that meets the design goals" seems to be a good
operating principle for me.

As far as a metric, we need at least a rough one, just to define simplicity
and to be able to compare the simplicity of two things. Whoever suggested
the effort of implementability is on the right track. I would add to that
some measure of the effort required to understand the spec itself (how clear
is the spec to the intended audience of developers). Of course this really
measures complexity, but simplicity can be viewed as its inverse (just to be
geeky):

complexity = (time to implement) + (time to understand specification)
simplicity = 1 / complexity

-Aaron

-----Original Message-----
From: Jeff Lowery [mailto:jlowery@scenicsoft.com]
Sent: Thursday, January 03, 2002 11:05 AM
To: 'www-tag@w3.org'
Subject: RE: Is "simplicity" a useful architectural constraint?


[Repost. Seems to have got lost.]

> 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 14:25:01 UTC