James Governor's Monkchips

The Lesscode Manifesto

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Ryan Tomayko is emerging as a key spokesman for the getting things done without complexity crowd.

Go read this piece called Motherhood and Apple Pie. Then subscribe to the feed.

I wish I could write so clearly. Actually, I wish I could think so clearly. Oh well.

3 comments

  1. I also wish I could write so clearly! I’m afraid, however, that the clarity of thought comes from looking at it from taking such a high vantage point that he doesn’t have to consider some ugly realities that one sees on the ground.

    For example, he says “These are the principles of design that have brought us where we are today and you can observe them working as designed in protocols and formats such as HTTP, URIs, MIME, HTML, and even XML (sometimes), and architectures such as REST” and goes on to discuss in some detail Tim Berners-Lee’s Axioms of the Web Architecture. There is a well-known alternative position that the success of the Web is not so much a proof of the power its professed axioms but a testament to what Clay Shirky calls “the strength of its weakness” [http://www.shirky.com/writings/evolve.html] : It produced useful results even when only partially implemented, it could evolve, and thus demonstrate that evolution is smarter than any designer, even Tim Berners-Lee and Roy Fielding. Admittedly many of the features of evolveable systems are also among Tim’s Axioms (especially simplicity, tolerance, and decentralization). The difference is that Orgel’s Rule suggests that trying to out-guess where evolution will take us next is bound to fail, whereas Ryan Tomayko seems to be trying to derive Theorems about the future from Tim’s Axioms.

    More empirically, for example it’s hard to square the clean principles of REST with the down-n-dirty reality of many (most?) real websites that use app servers to maintain server side state, require non-RESTful cookies to have a decent user experience, and often even ignore even explicit principles in the HTTP spec such as “no side effects with a GET.” I agree that at least the latter is Bad Practice, but it’s hard to argue on one side that the Web is as successful it is because of the purity of its design, and lament the almost universally poor quality of its implementation. Shirky’s alternative perspective, however, accomodates this very easily — the power comes from the shoddy implementation not the pure design.

    Also, I have to take issue with the various implications that big enterprises and software vendors don’t understand the Web and thus fail to reap its advantages. For example:
    “Instead of embracing the people, principals, and technologies that gave rise to this phenomenon [industry leaders] have chosen to subvert its history.” The reality I’ve seen after 5 years in a company that got most of its revenue from its mainframe software, a couple of years of involvement in web services standards, and a few months at Microsoft is a bit different: Business people respect the reach of the ‘Net, but suffer immense costs from worms, spam, phishing, viruses, etc. that stem from the general unreliability and insecurity of its infrastructure. That’s not to say that they want so impose an enterprise transaction processing ethic on the Web (which of course would kill it), but that they are extremely leery of building enterprise applications on worse is better principles. Much of what enterprise class vendors and consultants do is to try to let their customers have it both ways, or rather to find the sweet spot between the Web’s reach-ness and the enterprise’s richness.

    This is not to parrot “The rhetoric that suggests that the tools used to provide a brunt of the value on the internet are somehow expired, inelegant, or lacking in technical merit.” The tools that provide the brunt of the value on the web are well proven (not expired), and certainly have immense technical merit. They are not “elegant”, but that is Just Fine — they work for the Web. Whether they work in situations where reliability, security, non-repudiation, transactional integrity, and all that other “busienss” stuff are absolute requirements is much less well established.

  2. Hi Mike. I’m glad to see your take on this as I’ve respected your opinion for quite some time now (xml-dev lurker). We’re just going to disagree on some of this but I wanted to point out a few places where I think we’re closer in opinion than you think.

    “It produced useful results even when only partially implemented, it could evolve, and thus demonstrate that evolution is smarter than any designer, even Tim Berners-Lee and Roy Fielding. Admittedly many of the features of evolveable systems are also among Tim’s Axioms (especially simplicity, tolerance, and decentralization). The difference is that Orgel’s Rule suggests that trying to out-guess where evolution will take us next is bound to fail, whereas Ryan Tomayko seems to be trying to derive Theorems about the future from Tim’s Axioms.”

    I’m also of the opinion that great systems are grown/evolved and not designed, per se. I’ve said as much [http://lesscode.org/2005/07/09/whats-going-on/]. My intent is not to “drive Theorems about the future from Tim’s Axioms” but to suggest that the environment produced when these principles are followed provides the best soil for web-like systems to evolve in. I think that you can impact how well systems evolve by providing the right environment and Axioms provides a recipe for creating that environment on the web. TBL et al didn’t so much design the web as much as they designed an ecosystem where the web could evolve.

    “They are not “elegant”, but that is Just Fine — they work for the Web.”

    I think they’re elegant in that they closely follow the principles of the web. “Elegant” is defined as follows at dictionary.com:

    “Characterized by or exhibiting refined, tasteful beauty of manner, form, or style.”

    Beauty is, of course, in the eye of the beholder but I’m of the opinion that their form and style is very much in follow the web’s core principles. They aren’t elegant when evaluated from a traditional desktop or distributed business app background and that’s largely what I’m trying to get at.

    “Whether they work in situations where reliability, security, non-repudiation, transactional integrity, and all that other “busienss” stuff are absolute requirements is much less well established.”

    Indeed. And this is where I’m proposing a shift in mindset. I believe the way we’ve been thinking about moving these systems to the web has been backwards: start with what you know in the business app world and try to bend the web to meet it. The results are pretty poor, IMO. What I’m suggesting is that we should flip that thinking around: start with what we know about the web and bend the business app world to meet it. It seems a small difference but it’s important and has led me to the conclussion that we should be looking toward enhancing the tools that are so successful on the web to accomodate business instead of dumbing down tools that are successful in the old business world to meet the web.

    And it’s not just tools, it’s processes too. For instance, the processes that have evolved around F/OSS seem to play a role in creating that “evolveable ecosystem” we’re talking about.

    Anyway, like I said, I really appreciate you weighing in on this, Mike. I’ve been following you for some time now and I respect your opinion a great deal.

  3. “TBL et al didn’t so much design the web as much as they designed an ecosystem where the web could evolve.”

    Very nicely put, as usual. I agree. I think my main pushback, which may or may not be real disagreement, is that Tim’s Axioms and Roy’s dissertation are nice post-hoc theories to explain what they had in mind in a clear and fairly elegant way. They may or may not explain the success of the Web. Obviously it’s important to respectfully consider their positions, but I prefer to maintain some skepticism about how they might apply to the future evolution of the Web itself or or (especially) how they might apply to other large-scale systems such as those found in big companies.

    The main thing I learned from my stint in an Big Iron company is that someone will have to pry the secure/reliable infrastructures out of their customers cold, dead fingers 🙂 Internet/Web technologies have many virtues, but these are not among them.

    Some very smart people (e.g. at Amazon) have built secure and reliable apps on top of the Web, but it ain’t easy (witness the fact that Amazon so thoroughly dominates on the strength of its platform). It’s just not obvious to me how far the Web design pattern takes us into the world where information is private, reliability is critical, and “404 Happens” is a prescription for real-world disaster.

Leave a Reply

Your email address will not be published. Required fields are marked *