Dion Hinchcliffe's Web 2.0 Blog
Web 2.0 University

Blog Feed

Subscribe By E-Mail

Enter your email address:

Delivered by FeedBurner



Web 2.0 Expo San Francisco 2008 Speaker

Enterprise 2.0 Conference 2008 Speaker

Web 2.0 Strategies 2008 Speaker

    Recent Readers

    Web 2.0 Ajax SOA Power Panel

    Web 2.0, Ajax and SOA Power Panel with Dion Hinchcliffe and Jeremy Geelan
    Click above to watch a SYS-CON Power Panel discussion on Web 2.0, Ajax, and SOA with Dion Hinchcliffe, Jeremy Geelan, and other industry notables including SOA Web Services Journal Editor-in-Chief, Sean Rhody. Taped on Dec 7th, 2005 from the Reuter's TV studio in Times Square.

     

    Public Calendar

    News from the Field: Web 2.0 Best Practices

    posted Sunday, 12 February 2006
    Marc Hedlund set the blogosphere on fire today with a terrific new article on O'Reilly Radar that discusses the real things happening out there in the Web 2.0 development wild.  What I find so fascinating about the things we keep seeing is that ground truth seems genuinely different than it used to be.  Software development just appears to have somewhat altered rules when it comes to the next generation of the Web.  For one, the scale is so fundamentally different.  You might have hundreds of users, but chances are pretty good you could end up with millions.  So too are the tools that we use; new techniques are possible that just weren't before.  Even the control level is much different; the software and services that you write can be dramatically remixed, blended, hacked, and more.  And it's just supposed to be OK.

    But it's the scale in particular that encourages new ways of thinking about usability and testing.  If you read the comments to Marc's article, you'll find that many of them are from professional developers that just find it repugnant to ever let users co-test the software.  But I'm definitely starting to believe that perhaps that's the most efficient way to do it in this new world.  What's a 6 person development team when compared to the effectiveness of fifty thousand visitors a day?  As long as it's explicit - as in, this software is eternal beta - maybe the best way really is to enable the mongolian horde approach to finding bugs.  Users will expect to hit a few glitches (didn't they always?), and for their minor inconvenience, they also expect them to go right away.  Web 2.0 recognizes that the 1 billion users now on the Web can be harnessed to do many great useful things . And one of them is to be increasingly responsible for ensureing the high quality of the software they encounter.  Compelling stuff but scary for us used to the old ways of things.


    Web 2.0 Development Best Practices


    And Marc's laundry list of terrific real-world Web 2.0 development best practices goes beyond just letting the users test with the developers, like simple metrics, closely watched.  Another interesting concept is the shadow app.  Management tools for just about any level of the application stack are now available in abundance.  But they are generally faceless and generic fault detectors at best, and at worst actively trip up the systems they are supposed to be monitoring.  But shadow apps are little custom applications - those in software development know them well - that tell you what you really want to know about how the software is behaving and being used.  Like so many good ideas, Web 2.0 techniques talk about practical methods in concrete terms and we've all seen shadow apps informally, often just as a SQL script.  We rarely see it called by name however, much less recommneded as a key strategy.  Good on Marc for making this an explicit meme.

    I won't go into all the others, you can read them yourself.  I do want to add one final item, which I mentioned in my comment to Marc's post, that there is one other important piece in making Web 2.0 happen:  Lightweight, dynamic programming models, both in terms of terrific new languages like Ruby as well as excellent featherweight data structures like JSON, POX, and microformats.  These are making the small pieces, loosely joined happen.

    Update: Marc does another post on all the feedback he received. Surprisingly it was basically grouped into folks who disliked the "2.0" in his post title and those that disagreed with the Q&A piece (which I'm struggling with too but trying to keep an open mind.)

    A couple of notes:  One, I'm going to be in Silicon Valley with my co-author of Building Web 2.0, Kate Allen, starting this Friday evening February 17th for Michael Arrington's TechCrunch BBQ. I have about three slots on Saturday the 18th to interview Web 2.0 companies for the book (we're trying to get ground truth on Web 2.0 business models, development practices, etc.) as well as line up potential product reviews for the Web 2.0 Journal.  If you don't mind having a couple of friendly people take a look at what you do with your Web 2.0 startup, let me knowTwo, we're getting close to having enough Ajax authors, but we have room for a couple of more, also let me know if you'd like to work on an exciting short term writing project.

    What do you think Marc missed? The Web 2.0 development world is different, but is it really turning things upside down?

    links: del.icio.us    



    AddThis Social Bookmark Button

    1. didier durand left...
    Monday, 13 February 2006 12:42 am :: http://media-tech.blogspot.com

    I think this is incredibly close to what E. Raymond, the father of Open Source, wrote in his famous "The Cathedral and The Bazaar" 6-7 years ago

    Check it out at http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

    Just another iteration with the most recent technologies?


    2. Otis Gospodnetic left...
    Monday, 13 February 2006 2:36 pm :: http://www.simpy.com/

    I haven't read Marc's article just yet (waiting in a new tab), but I do have a few comments about some of the things you said:

    - Micro-releases - sure, that was always possible, and nothing has changed recently that makes this more possible than, say, 5 years ago. It's merely a state of mind, an attitude.

    - Regarding the eternal betas and QAing by users as opposed/in addition to the 6-person team, while I agree that companies/services can engage users into testing, this again is nothing new and has been possible for a long time. Again, state of mind and attitude. :) As for eternal betas, I don't think services need to be in eternal betas. Take a look at Simpy - you won't see any beta disclaimers anywhere. Software, unless made for airplanes, military, etc., tends to be in permanent development/beta. Labeling it as such is redundant. Furthermore, why does the whole service need to be labeled as beta? User registration, login, and similar core functionality better be working 100%, or else you'll see no action. Perhaps companies should label only new facets of a service with beta.

    - More on QAing by users - with so many services being 100% free and scrambling to figure out a way to make money while still keeping the service free, users better be willing to help out with services they really like and find useful. For instance, Simpy has some dedicated users who get early access to new features and provide feedback before others get to use the new stuff. They help me, and I give them something they find useful. A happy symbioses. :)


    3. Brad Neuberg left...
    Monday, 13 February 2006 7:49 pm :: http://codinginparadise.org

    Hi Dion! I should be at the TechCrunch party as well this Friday; we should chat and finally meet.

    Best,

    • Brad Neuberg

    • bkn3@columbia.edu

    • http://codinginparadise.org


    4. Otis Gospodnetic left...
    Tuesday, 14 February 2006 1:53 am :: http://www.simpy.com/

    Hi Dion,

    One question for you.

    I see/hear this "Ruby/PHP == lightweight/dynamic == easy/fast to program/make changes/fix bugs/release". Why exactly do you say this?

    Old guard: Perl == dynamic/scripting language. Python == dynamic/scripting language.

    What I often see is somebody mentioning Ruby or Ajax as something that almost completely removes the pain of adding new features or bug fixing. Sure, Ruby can be elegant, but it still requires ... programming.

    Another old guard lingo: Java. What stops a Java app from all those lightweight things that people love to couple Ruby with?

    To me these Ruby vs. Old Guard claims often seem wrong, so I thought I'd ask... :)


    5. Dion Hinchcliffe left...
    Tuesday, 14 February 2006 9:48 am :: http://blogs.zdnet.com/Hinchcliffe

    Otis:

    A brilliant question and one that I think is on a lot of people's minds, so I will try to answer to the fullest extent possible.

    I used to ask myself the same question but with all the positive hype, I thought it was time to find out for myself. So I sat down and did my best to learn Ruby and along with the reasons why it was designed the way it was.

    In the end, I came away favorably impressed, especially when compared to older languages.

    First, Ruby (and I would assert all good languages) are specifically designed with the realization that software is written once, changed 100 times, and read 1000 times. It has an elegance when read that is impressive and its syntax encourages readability and comprehension.

    This makes Ruby code surprisingly clear and easy to maintain, even by people who didn't write the original code.

    I can personally vouch for all this, with examples in a moment even!

    Second, Ruby makes the modern Web features we need most in our languages (HTTP support, XML processing, and others) natural, fluid extensions instead of awkward first generation libraries.

    To demonstrate this, a few months ago I wrote three identically functional loosely-coupled command-line Web services clients, each in Java, C#, and Ruby. I came away =impressed with the results:

    Java was the ugliest and most difficult to write by far and it was extremely hard to get the code to do the right thing as expected. C# was a bit easier but still had lots of code required. Then, not knowing the language well, I wrote the Ruby client in easily 1/3 the time and in about half the code of the Java version.

    The code is available for inspection (admittedly, not super clean, but compact for comparison) at the bottom of this post and the Web service is still live to test. I tried to make each Web service client have the exact same features.

    In any case, if you look at the source, you can easily see one particular lanaguage (yes, Ruby) is just so much more readable and straightforward. Common sense says this will be less buggy, especially over time. And just on the basis of keystrokes alone, the savings will add up. Despite this, Ruby is still not terse. And the library support is well-designed to the point that using XML, XSL, file access, or most other things we're likely to need all work the same way and as simply as possible.

    Draw your own conclusions, but combined with the Ruby on Rails framework, it's a compelling story that makes development, maintenance, and change a much different experience that older languages that don't benefit from all the learning we've done about good programming in the last ten years.

    </end waxing poetic>

    Best,

    Dion


    6. Dion Hinchcliffe left...
    Tuesday, 14 February 2006 10:16 am :: http://blogs.zdnet.com/Hinchcliffe

    Brad,

    Great stuff, looking very much forward to meeting you.

    Best,

    Dion


    7. Sarang left...
    Tuesday, 23 May 2006 6:04 am :: http://www.teknowlogy.blogspot.com/

    Hi Dion,

    Really great stuff. I was really confused whether I should use Ruby On Rails for one of the Web2.0 ideas I want to implement. I read some forums and got more confused. Now, after reading this at least I am convinced that I will go on with Ruby On Rails - will give it a shot.

    Luv Olweiz, Sarang.