Re: Is "simplicity" a useful architectural constraint?

On Wednesday, January 02, 2002, 10:18:10 PM, Tim wrote:

TB> However one may choose to characterize the architecture of the
TB> web, there is universal agreement that qualitatively speaking,
TB> it's pretty simple.

Well, maybe. There are companies that have tried and failed to make a
Web-browsing product due to the staggering complexity of
reverse-engineering required to implement the unwritten
specifications.

But lets assume that we are talking about W3C specifications, and then
I agree that simplicity is one (not the only, not the most important)
success metric. At this point I would quote Einstein except that has
already been done, twice, in this thread.

TB> It's my opinion that this simplicity is one of the reasons it 
TB> has worked to date.  Further, that this simplicity needs 
TB> to be defended actively, since there are active pressures in
TB> the direction of complexity creep.  The pressures range widely,
TB> from vendors wanting to reduce the semantic gap between the Web
TB> and their complex, overgrown data access protocols, to simple 
TB> facts of life such as large working groups.

I agree that these pressures exist and that what they are adding is
*un-necessary* complexity, at least from the point of view of those
who do not have those problems to solve or who have subtly different
ones.

TB> Trouble is, simplicity is not quantifiable so it's hard to
TB> write rules.  But I think the Web and the W3C would both have
TB> been well-served if at a couple of points in recent years 
TB> some voice could have spoken ex cathedra saying "This is
TB> too complicated.  Go back and throw some of it away or find
TB> another way to fix the problem."  -Tim

 Certainly its hard to objectively quantify, and it is a relative
 measure - complexity per capability added, not just complexity. Its
 easy to make an uncomplicated spec, as long as it solves a trivial
 and well-isolated problem and no other working groups care what the
 result looks like ;-)

 Throwing some of it away is a poor approach, though. The popularity
 of Directors cuts DVDs shows that taking a two hour 15 minute film
 and trimming down to some notion of correct size does not make a good
 two hour film - it makes a film with puzzling jumps and bits missing.
 To continue with the analogy, it optimizes it for the initial
 consumers (cinemas who need to get three showings per evening not
 two) at the expense of the later, and more numerous consumers
 (purchasers of DVD and video, TV stations) who don't have those
 particular constraints.

 Its easy to reduce the apparent complexity of a spec by cutting out
 all the examples, by not defining behaviour at edge cases, or by even
 not stating what the edge cases are and leaving them as emergent
 properties of the formalism used to tersely describe the spec. That
 does not make a better spec though, and increases one of the
 complexity metrics (time to implement) suggested by other responses
 in this thread.

 A good way to reduce the complexity, on the other hand, is to have an
 alternative proposal coming out of public review that carefully
 presents an alternative approach which has frwer gnarly edge cases,
 where the common cases fall out naturally, which achieves the same
 result as an existing (portion of) the specification but in a simpler
 and more natural way, etc. But that does require a significant time
 commitment from the proposer. And it requires a willingness of the
 working group to reconsider, to throw away something they made, to
 verify that it covers the cases they consider important, etc.

 One last point. Making a spec simpler by covering less edge cases and
 less 'glue' with other specs may make it seem simpler, but then the
 implementors of several specifications in one product have to
 scrabble around to make up the shortfall - or the users (content
 developers) have to stitch it together themselves with kludegy script
 hacks. When evaluiating complexity, its also necessary to ask
 'complex for whom?'

-- 
 Chris                            mailto:chris@w3.org

Received on Friday, 4 January 2002 07:10:30 UTC