It Ain't Easy to be Simple

re: It Ain't Easy to be Simple

Mark Baker — Wed, 09 Mar 2005 15:38:00 GMT

I like what Merriam Webster has to say about "simple";

"9. readily understood or performed"

As in "It's simpler to integrate services when they expose the same interface, than it is when they expose different ones".

re: It Ain't Easy to be Simple

Mike Champion — Wed, 09 Mar 2005 17:16:00 GMT

Not that we've ever argued about this before :-) but to me, "interface" means the specification of the operations, and the data, and the details of any higher-level application protocol that is exposed in a multipart service. By the time you do all that in a real-world, machine-machine, multi-stage, mission-critical REST application, you will have reinvented much of WS-*. In that case, you end up something that is "simple as in clean" , but with numerous details of the formats, not to mention the details of the hypermedia that defines the application state machine, that make it any thing but "simple as in easy."

re: It Ain't Easy to be Simple

Mark Baker — Wed, 09 Mar 2005 18:50:00 GMT

Are you sure we've been over this one before? 8-) I'll try to simplify (as in "make readily understood" 8-) my point by removing data from the equation ...

When getting *exactly the same data* from multiple services, it's simpler if all those services expose the same interface, since it means that in order to support N services, I only need to do one chunk of work rather than N.

Complexity is not always preserved. Simplification is possible. Architectural constraints which induce simplicity are required.

re: It Ain't Easy to be Simple

Oleg Tkachenko — Thu, 10 Mar 2005 13:19:00 GMT

Oh, I recently wrote on Derek's blog that I need a "simple" API. Now I see how shallow it was.

re: It Ain't Easy to be Simple

Mike Champion — Thu, 10 Mar 2005 13:53:00 GMT

Oleg is referring to my colleague Derek Denny-Brown, who talks about the XML API challenge we are wrestling with at http://nothing-more.blogspot.com/2005/03/serving-many-masters.html. "Shallow" or not, my question to you Oleg is what kind of simplicity do you want? Do you want XOM's design goals of being "easy" (for people who deeply understand XML anyway)? Or do you want more conceptual "cleanness"? That is pretty hard to achieve with XML, because it is rather conceptually messy once you get past elements/attributes/text, and challenging because the XML schema types don't mesh cleanly with the .NET types (or Java types, which XOM neatly gets around by not supporting schemas ... but our customers are not so willing to let us get away with that!). In other words, do you want an API that is simple to learn in that it has a minimal number of classes and methods, or one that is simple to use because it has lots of built-in features to do all sorts of common combinations of operations?

Most importantly, is anybody really willing to give up the comfortable "simplicity" of what they already know, and go to the effort of learning a "simpler" API?

re: It Ain't Easy to be Simple

Radovan Janecek — Thu, 10 Mar 2005 22:27:00 GMT

Hey, I'm not snarky - I have fun! ;-)

re: It Ain't Easy to be Simple

Mike Champion — Thu, 10 Mar 2005 22:49:00 GMT

I was being snarky by letting you do the talking :-)

re: It Ain't Easy to be Simple

Kurt Cagle — Sun, 13 Mar 2005 22:56:00 GMT

Mike,

Thanks for the link. I think that you're absolutely correct here, not in contravention to what I previously wrote, but that the struggle for simplicity often tends to become an issue of what vector in the complexity bundle you most wish to optimize.

I have long believed that your statement "Today it seems that keeping protocols simple and placing more significance on the message doesn't decrease complexity, it just moves it around." is true about programming in general. Programming is the art of of figuring out where best to dump the complexity inherent in any human domain problem, and I've often wondered if complexity is inherently a zero-sum game: you can never destroy complexity, you can only redistribute it.

-- Kurt

Authentic Analysis and Argumentation?

mikechampion's weblog — Fri, 22 Apr 2005 16:35:03 GMT

I've been a bit out of the habit of writing here - for the last couple of months most of my free time...

Writing less code

mikechampion's weblog — Mon, 19 Sep 2005 07:43:00 GMT

Who said "There's only really one metric to me for future software development, which is
-- do you...

Microsoft XML Team s WebLog It Ain t Easy to be Simple | Green Tea Fat Burner

Microsoft XML Team s WebLog It Ain t Easy to be Simple | Green Tea Fat Burner — Tue, 09 Jun 2009 22:19:51 GMT

PingBack from http://greenteafatburner.info/story.php?id=4528