Life 2.0 is a perpetual beta release.

15 March, 2007 // Rob // Web 2.0, Google, Blogging

Life 2.0 is a perpetual beta release.The other day, I mentioned a particular idea in this article by Joshua Porter at Bokardo: Everything is beta. In his terms, he means that his blog is an arena where unrefined or partial thoughts can gel into more cohesive ideas and arguments. I’ve been thinking a lot about that idea this week, and I think that this concept can be applied to everything everything and not just to blogging.

Traditionally, a beta release was a step in the release cycle of software. When the developers of a particular piece of software decided to stop adding new features, they would release a beta candidate for users outside of their development group to kick the tires and make sure everything was working properly. With the advent of the open source movement and the rise of Web 2.0 technologies, a more collaborative, dynamic publishing platform for applications surfaced, and some companies chose to make the software release cycle transparent, leaving their applications in a state of perpetual beta.

Google’s Gmail is a great example of this. Gmail is a fully functional application for the Web, but Google constantly adds new features and refines existing ones. They’ve had the “beta” tag on the Gmail site for years, but the service isn’t unfinished or unpolished. With Gmail, Google has skipped the traditional model of software release and acknowledged that their application will continue to evolve and grow. Gmail will never be finished, and because of the capabilities of Web technology, it never has to be.

You can probably see where I’m going with this. Life is in a state of perpetual beta release, too. Think about who you were a year ago and think about who you are now. Chances are you don’t think of yourself as Me 1.0 and Me 2.0. More likely, you see yourself as the same person now as you were then but with new experiences: Mebeta.

So, how can some of the themes of Web 2.0 help your Life 2.0 in its state of perpetual beta (bullet points are borrowed from this excellent article by Tim O’Reilly)?

1. Trusting users as co-developers
Now more than ever before, humans are constantly connected to each other. We’ve got cell phones and text messages, emails and blogs, and a plethora of Web applications created to keep up the conversation. (I’m looking at you Myspace.) As you interact with people, you learn and grow in ways you never could on your own. So don’t shy away from these services. Start participating and change the folks you come in contact with as much as they’ll change you.

2. Software above the level of a single device
Don’t be limited by one track. For example, I’ve got an English degree, and I’ve managed to become a Web developer. Specialization is still necessary, but let yourself become conversant in other disciplines. Become cross-browser compliant!

3. Lightweight user interfaces
At its most basic, Google is a logo and a search box. But beneath that simple surface is a devastatingly complex core. Translation: don’t be lured in by the trappings of the superficial. Look beneath the surface of things for their value. And conduct yourself in the same way. Be direct. Be simple. And be amazing.

4. The Perpetual Beta
This one is simple: try new things. You are you. That is your core service. But you should continually add features. Develop a love of French cinema. Learn how to sail. Start lifting weights. Or, in a business context, voluntarily add skills to your basic skill set. The beta testing of your life should continue until you die (Me 3.0?). Otherwise you’ll wind up just another stale version of MS Office languishing on a shelf at Staples.

Life is a precious gift, but it’s also a responsibility. If you live in a state of perpetual beta, you’ll be able to squeeze every ounce of worth out of it.

Leave a Response / Trackback

4 Responses to “Life 2.0 is a perpetual beta release.”

  1. Robert says:

    03/16/07 at 9:33 am

    Since I never have anything other than clipped, random thoughts, I’ll spill them here in whatever order they fall.

    1) Perpetual State of Beta - This is not something that I feel should be a design goal for two reasons. First, it absolves people of responsibility for their product. People just shrug off foibles or bugs saying “Oh, its still beta.” Second, it prevents wide scale adoption of the technology because of the uncertainty in development direction. At best, Beta should be a transitory state.

    2) Requirement Refinement by Prototype Development - This is actually what I think you might be talking about. Traditional software development is focused around the gathering of “requirements” and then their implementation in some production quality tool. Many people have spent countless hours trying to design a process that will encompass the broad scope of requirement gathering. I think they’ve all failed. What I like is for a bare set of requirements and design goals to be given to the developer. Then the developer prototypes the site (with mockups, pictures, real code, whatever) and the customer examines the prototype, plays with it and refines his ideas about how it has to work. I read a study that this is how American developers prefer to work, whereas in India, developers prefer to get a detailed set of specifications and code directly to that.

    3 The Life Beta analogy - One way (of many) that I look at my life is that it is a bunch of little components that have some occasional interaction. Each little component is in varying degrees of completeness. Some are very complete production releases. Some are still very beta. I can only manage so many betas in my life.

    4 Users as co-developers - Interesting way to put it. We talk about something at work called emergence. So when you have all these random people looking at a problem, sometimes patterns emerge. Sometime solutions emerge. Sometimes these solutions are vastly superior to what you could come up with on your own. Only problem is that it is not reliable. Sometimes you find bad soultions instead and get lead down the primrose path.

    5 I have more thoughts, but I tire.

  2. Rob says:

    03/16/07 at 10:31 am

    You should start a blog, Robert. You know you want to. To your comments:

    1. You’re referring to “beta” in the traditional sense, which if you are developing a software product, should absolutely be a transitory state. How could you offer anything for final sale if it’s never finished? But I think beta has a new meaning when it comes to applications on the Web, which tend to be free services rather than products for sale. By nature, they have to remain fluid and dynamic in order to facilitate the collaborative community of their users. I think applying the term “beta” to Web apps is something you’ll start seeing less and less of because the term lacks meaning in that context. If you haven’t, read that article by Tim O’Reilly that I link to in this post.

    2. I don’t think this is exactly what I’m talking about, but you know more about the methods of software development than I do. What you describe is a collaboration between developer and customer, though, which is the essence of Web 2.0. The only thing I would add is that by nature, these Web apps we’re discussing require a constant cycle of requirement refinement (perpetual beta?). And because of the direct and constant connection between developers and users on the Web, these cycles happen faster than anything in traditional software development.

    3. I agree that our lives can be broken into segments of varying degrees of development. But I don’t believe that any of these segments is ever finished. Maybe they are developed to the point of being usable or even useful, but there is always more to learn and more to experience.

    4. That line is cribbed from Tim O’Reilly’s article. I agree completely with your point here. The risks of the collaborative development are as great as the rewards. But that’s where we have to exercise wisdom to determine what to trust and what to look past. Just as developers have to decide what to include and leave out of their applications, we have to decide what influences will effect us in life.

    5. Get some sleep!

  3. Robert says:

    03/16/07 at 4:18 pm

    I’m not the most eloquent of people and I’m probably not communicating my thoughts well, but I’ll try

    I don’t think you’re response makes sense to me. How can anything that is a beta and by your definition changing somewhat frequently, ever be used in a business workplace (irrespective of its free-ness)? Rarely have businesses ever used something that is unstable like that no matter how cool. I also think people want to draw these distinctions between web apps and regular apps and declare them apples and oranges, but that doesn’t make sense to me either. Why are they different? Because one exists in a web browser? All that same flexibility can be coded in a thick client app, probably for a similar cost to a thin client. I think it is an artificial distinction. All this interface/usability stuff is equally applicable to both platforms. The only major difference seems to be ownership. Thick Clients are on your computer and you have some degree of control over them. Thin Client apps reside elsewhere and can be changed easily (this causes many problems as well as benefits).

    I think that you’re trying to extend the meaning of the word “beta” to say that things should be flexible and receptive to change. I think that’s a bit of a stretch. Beta applications rarely change substantively in anyway and most of the time they just are used to identify key bugs and minor usability issues.

    My point about breaking our lives into manageable parts is that, we can only manage so much change, flexibility or beta. Some things have to be held constant while others change. If you’ve worked at something to the point where you have worked out most of the bugs and are using it regularly, then its probably not beta anymore anyway. If you re-work that module, then you’re not throwing it back into beta, it’s a new version. Component 3.21

    I’m not much of a blogger and I don’t know what the right way to contribute to a blog is. I do know that the power of a blog is directly proportional to the amount of discussion it generates, so more powere to you, Rob.

  4. Rob says:

    03/16/07 at 5:29 pm

    Robert, my initial post was not meant to rewrite the rules of software development. My observations on Web technology as influenced by this article were meant to create an analogy between O’Reilly’s definition of “Web 2.0″ and the way we live our lives. I chose the term “beta” as a response to this post, which uses beta to mean unfinished or incomplete. I’m sorry you have a problem with the way I’ve chosen to apply the term beta to my thesis, but I’m not sure how to relate it any more clearly than I already have.

    You have taken the debate to a level that my original post was never intended to go. I’m not a software developer like you are, and as such, my frame of reference to continue this conversation is much more limited than yours. My article was meant to be inspirational and interesting, not a scientific paper about the pros and cons of thin client apps.

    To answer a few of your points: there is a difference between being dynamic and being unreliable. The folks at 37signals have been offering dynamic, Web 2.0-type applications for business purposes for quite a while now. Also, Web apps like shopping carts are thin client apps that are used in ecommerce all the time. Paypal, ebay, google, amazon, etc… all use thin client apps to facilitate business.

    I agree that we can only manage so much change at one time. If you want to look at aspects of your life as final release software, go right ahead. My life is made up of unfinished segments that I either continue to develop or abandon by design.

    You’ve brought up some good points, and I appreciate your thoughts. You have opinions and things to say. I think you could do well with a blog.

leave a reply