SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for September 14th, 2007

Reaching all the Web 2.0 Personality Types (Part 3 on Web 2.0 Personality Types)

Posted by Bob Warfield on September 14, 2007

I’ve been thinking more about Web 2.0 Personality Types as I read bloggers who are wondering whether it’s right for them to use Facebook, start a Corporate Blog, or do some other Web 2.0 thing.  If you subscribe to the Web 2.0 Personality Type theory, you need to cast a wide net lest you miss an entire audience with a particular Personality Type.  I’ve written about several recent examples where companies are casting broad nets across multiple Web 2.0 Personality Spaces:

To fully leverage Web 2.0 communication and collaboration you have to hit as much of the Web 2.0 pesonality Space as possible.  In this post I want to put a little more color into what each of the various personality styles is looking for:

Interrupted | Deferred:  Needs motion to attract their attention like Jurassic Park’s TRex |  Wants time to digest a relatively static scene

Fast changing information drives the interrupted audience.  These folks are extreme extroverts who have to be interacting with people all the time.  Who wouldn’t wnat the Interrupted/Extrovert audience on their side?  Give them capabilities like Twitter, things that change constantly on your web page, and information feeds that “push” rather than forcing these individuals to “pull” are important.  Make sure that your blogs and other content have lots of buttons to enable feeds to the Interrupted Viewer’s mind space.  With so much information coming at them, you need to be concerned that an Interrupted Viewer can lose interest in your offerings very easily if you don’t feed them a lot of change.  In terms of initiating direct contact, the Interrupted Viewer wants it now and they expect you to be receptive now as well.  Provide them avenues to inject their responses as immediately as possible so that InterruptedParticipator’s are not put off.  Interrupted Viewers are easy to catch once, but they are the hardest to keep loyal.

Examples for the Interrupted audience:  Twitter, Data Feeds, Blackberry, Phone Text Messages, Web Cams, Skype, Push a button and chat with or be called by a Sales or Support person.

The Deferred Viewer feels too much change equals too much distraction.  It forces an audience that may be introverted to play along too much rather than sitting back comfortably to watch.  It drives them away.  If you put gadgets on your page that change constantly, keep them relatively small and unobtrusive.  Make it easy to turn them off.  The Deferred Viewer wants to “pull” their information.  Perhaps it helps them to feel more in control, or at least to feel like they manage their time more effectively.  Deferred Viewers want to initiative contact on their own terms.  Make them do as little as possible on a single focus and let them choose what they want to do and when they want to do it.  These are the hardest Viewers to capture as a repeat audience, but once you do, they will be the most loyal.

Examples for the Deferred audience:  Search, Blogs, E-Mail, Forums, Wikis, Maps, Photo Galleries, and Videos.

Text | Video/Multimedia:  Prefers written words |  Loves videos and other rich media

Text Viewers are verbal thinkers.  Feed them crisp clear prose that is well written.  Keep the UI as simple as possible.  Prefer textual menus and labels on buttons.

Examples for the Text Audience:  Google UI.  Blogs.  E-Mail.  White Papers.

Multimedia Viewers are visual thinkers.  Feed them tons of images.  Communicate ideas visually.  Avoid giant pages of text unbroken by any imagery.  Consider video.  Rich user interfaces are welcome.  Icons are welcome.

Examples for the Rich Multimedia Audience:  Images.  Data Visualizers.  Mind Maps.  Video.  Rich UI.

Free Form | Structured:  Thrives on chaos | Prefers structure

The FreeFormer wants to view the trees without being burdened with the Forest.  Don’t force their thinking into a rut you have chosen.  Let them see what you’re offering from a holistic perspective.  FreeFormers are Intuitive thinkers.  Focus on things that feel good.

FreeForm Examples:  Keyword Search is completely free-form.  Don’t overly control how they express themselves:  MySpace is more FreeForm than Facebook.  Start from a conclusion and tell why it is good.

The Structured Thinker wants to understand how the trees fit together to make a forest.  The best thing you can give them is a new structure for how to fit the ideas you’re tossing them together.  Let them see what you are offering as components to be re-combined into structures you’ve provided as well as structures of their own choosing.  The Structured crowd are more likely to be Rational thinkers.  Focus on things that make sense and are logical.

Structured Examples:  Wikis, Timelines, Threads/Forums, and any other mechanism for imposing structure.  Prefer tables over more abstract diagrams.  Prefer outlines over boxes and arrows.  Start from component parts and assemble them into a conclusion.

Watcher | Participator/Shaper:  Likes to watch | Driven to participate

The Watcher wants to take input and new messages on their own time.  They may do this because they’re more introverted, or because they cannot afford to allow your messaging to derail more urgent priorities (i.e. they are very busy).  To win the Watcher over you must keep their interest.  Get your best ideas out in front of the Watcher.  If you surprise them with an idea they love and hadn’t heard elsewhere, you’ve won them over.

Watcher Examples:  Blogs, Newsfeeds, Social Bookmarking

The Participator/Shaper insists on adding their 2 cents.  They crave opportunities to collaborate with you and to influence your direction.  If they are extroverted, they do it for the contact.  If they are introverted, they do it because they’re captivated by your idea and want to participate in its energy.  To win the Participator over, you must show some willingness to let them participate in implementing or shaping your vision.  Give the Participator a role to play.  Don’t fill in all the blanks.  Ask for their help.

Participator Examples:  Wikis they can contribute to, Forums instead of Blogs, Blogs with lively commenting.  Kyte, because they can watch the video and then discuss it with others.  Crowdsourcing is ideal for Participators.

Putting it All Together

We’ve seen how to attract the attention of the various personality types.  Consider how these types interact in combinations as well:

– InterruptedRichMediaParticipators will want you to be able to stop everything and communicate with them in rich media.  Push a button and get a Skype connection to a live person at your end, for example.

– DeferredWrittenWatchers will likely want to restrict two way communication to e-mail or perhaps blog comments or forum threads.  They will often seem to be ignoring your messaging unless you can somehow make responding imperative without annoying them.  Anything more forward will seem too jarring to them.

It’s possible you can infer that most of the audience you are reaching fall into a particular type.  This is usually only a possibility if you’re targeting a fairly narrow niche.  Failing that, you need to decide whether to try to cover as much Style Space as possible, or to focus on being really really great on a particular set of styles that reach a large enough audience.  Sometimes its hard to crossover to a new Medium.  Stephen Spielberg makes great movies, but I’m not sure he can write a best-selling novel as well as John Grisham. 

Most successes will be born of starting with a focus and then broadening the footprint over time.

Submit to Digg | Submit to Del.icio.us | Submit to StumbleUpon

Posted in Marketing, user interface, Web 2.0 | 3 Comments »

Guido is Right to Leave the GIL in Python, Not for Multicore but for Utility Computing

Posted by Bob Warfield on September 14, 2007

There’s been a lot of back and forth in the Python community over something called the “GIL” or Global Interpreter Lock.  Probably the best “get rid of the GIL” argument comes from Juergen Brendel’s post.  Guido, the benevolent dictator of Python has responded in his own blog that the GIL is here to stay and he doesn’t think it is a problem nor that it’s even the right choice to try to remove it.  Both combatants have been eloquent in expressing their views.  As is often the case, they’re optimizing to different design centers and likely will have to agree to disagree.

Now let’s try to pick apart this issue in a way that everyone can understand and make sense of for large scalability issues in the world of SaaS and Web 2.0.  Note that my arguments may be invalid if your scaling regime is much smaller, but as we’ve seen for sites like Twitter, big time scaling is hard and has to be thought about carefully.

First, a quick explanation on the GIL.  The GIL is a bit of code that causes multiple Python threads to have to wait before an object can be accessed.  Only one thread may access an object at a time. 

Whoa!  That sounds like Python has no ability to scale for multiple cores at all!  How can that be a good thing?  You can see where all the heat is coming from in this discussion.  The GIL just sounds bad, and one blogger refers to it jokingly as the GIL of Doom.

Yet all is not lost.  One can access multiple cpu’s using processes, and the processes run in parallel.  Experienced parallel programmers will know the difference between a process and a thread is that the process has its own state, while threads share their state with other threads.  Hence a thread can reach out and touch the other thread’s objects.  Python is making sure that when that touch happens, only one thread can touch at a time.  Processes don’t have this problem because their communication is carefully controlled and every process has its own objects.

Why do programmers care about threads versus processes?  In theory, threads are lighter weight and they can perform better than a process.  We used to argue back and forth at Oracle about whether to use threads or processes, and there were a lot of trade offs, but it often made sense to go for threads. 

So why won’t Guido get rid of the GIL?  Well, for one thing, it was tried and it didn’t help.  A new interpreter was written with fine-grained locking that minimized the times when multiple threads were locked out.  It ran twice as slow (or worse on Linux) for most applications as the GIL version.  The reason is that having more lock calls was slower:  lock is a slow operating system function.  The way Guido put this was that on a 2 processor machine, Python would run slightly faster than on a single processor machine, and he saw that as too much overhead.  Now I’ve commented before that we need to waste more hardware in the interest of higher parallelism, and this factor of 2 goes away as soon as you run on a quad core cpu, so why not nix the GIL?  BTW, those demanding the demise of the GIL seem to feel that since Java can run faster and supports threads, that the attempt at removing the GIL must have been flawed and there is a better way.

I find myself in a funny quandry on this one, but ultimately agreeing with Guido.  There is little doubt that the GIL creates a scalability speed bump, but that speed bump is localized at the low end of the scalability space.  If you want even more scalability, you still have to do as Guido recommends and use processes and sockets or some such to communicate between them.  I also note that a lot of authorities feel that it is also much harder to program threads than processes, and they call for shared nothing access.  Highly parallel languages like Erlang are focused on a process model for that reason, not a thread model.

Let me explain what all that means.  Threads run inside the same virtual machine, and hence run on the same physical machine.  Processes can run on the same physical machine or in another physical machine.  If you architect your application around threads, you’ve done nothing to access multiple machines.  So, you can scale to as many cores are on the single machine (which will be quite a few over time), but to really reach web scales, you’ll need to solve the multiple machine problem anyway.

As Donald Knuth says, “premature optimization is the heart of all evil in programming.”  Threads are a premature optimization when you need massive scaling, while processes lead to greater scalability.  If you’re planning to use a utility computing fabric, such as Amazon EC2, you’ll want processes.  In this case, I’m with Guido, because I think utility computing is more important in the big picture than optimizing for the cores on a single chip.  Take a look at my blog post on Amazon Startup Project to see just a few things folks are doing with this particular utility computing fabric.

Submit to Digg | Submit to Del.icio.us | Submit to StumbleUpon

Posted in amazon, data center, ec2, grid, multicore, platforms, saas, software development, Web 2.0 | 4 Comments »

Microsoft to Adopt Asymmetric Marketing to Keep Up With SaaS

Posted by Bob Warfield on September 14, 2007

I’ve always liked Joe Bentzel’s concept of “Asymmetric Marketing” as reported in his Redmondista! blog.  He recently gave a pretty good definition of the idea:

Asymmetric Marketing is when an “ISV creatively coopts the market momentum of an incumbent market superpower in order to accelerate its own success.

The young Microsoft did this with IBM in PCs. The young Google did this with Yahoo in sponsored search. The young Adobe did this with Apple in desktop publishing. The young Oracle did this with Digital Equipment Corporation in relational databases.”

It’s an elegant business jiu jitsu move that uses your opponent’s strength as your biggest advantage.  Imagine my surprise when I read Joe’s recommendation that Microsoft turn a Vista failure into a strength by suggesting that their auto-update feature is like SaaS only even better.  It sure sounds like Joe thinks Microsoft needs to employ some asymmetric marketing to keep up with SaaS which is otherwise a scary prospect for the company.

I write this only slightly tongue in cheek.  BTW, auto-update is cool, but it takes a lot more services than that to put Microsoft into a position to really deliver SaaS.  The unfortunate part about it all is that the steps they’d need to take invalidate years and billions of dollars of investment in creating their operating system monopoly.  Still, I won’t bet against the ‘Soft.  Maybe they can try Asymmetric Marketing.  When the big guy uses it on the little guys, it sounds suspiciously like Microsoft’s well-known Embrace, Extend, and Extinguish strategy.  Maybe the ‘Soft is still a Redmondista after all!

Posted in saas | Leave a Comment »

Twitter Scaling Story Mirrors the Multicore Language Timetable, Yields 10000% Speedup

Posted by Bob Warfield on September 14, 2007

There’s a great story over on the High Scalability blog about how Twitter became 10000% faster:

For us, it’s really about scaling horizontally – to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January.

This is the story I wanted to tell in Multicore Language Timetable:  a faster language pales in comparison to a more scalable language.  In this case, Twitter didn’t have that luxury, Ruby wasn’t more scalable, but it did have sufficient facilities that they could rearchitect their app for horizontal scaling, which is utilization of more cores.  It’s also the story of how the Multicore Crisis is here today and many of you have already experienced it.

Twitter learned several interesting lessons along the way that I’ve been hearing more and more:

  • Don’t let the database be a bottleneck.  We had the same view at Callidus, the Enterprise Software company I last worked at.  We build a grid architecture and managed to offload enough so that a typical configuration was 75% Java grid computing array and 25% database.  This was for a radically more database-intensive (financial processing) business application than most Web 2.0 apps like Twitter.
  • You have to build it yourself.  Unfortunately, there’s a lot of “almost” technology out there that doesn’t quite work.  That’s really unfortunate because everyone keeps hitting this horizontal scaling problem and having to reinvent the wheel:  70% of the software you write is still wasted.
  • Conventional database wisdom often tragically impairs scalability:  More and more companies are denormalizing to minimize joins and leaving relational integrity as a problem solved outside the database. 
  • “Most performance comes not from language but from application design.”  That’s a quote from the article, but I maintain it is also an artifact of using languages designed for a fundamentally different problem than what web scale applications face today.  Because the languages aren’t meant to solve the scaling problem, we shouldn’t be surprised that they don’t.

Interestingly, Twitter still has 1 single mySQL DB for everything.  It is massively backed up by in-memory caches that run on many machines, but at some point it can become the bottleneck too.  They’ve worked hard to de-emphasize it, but ultimately they have to figure out how to horizontally scale that DB.

Submit to Digg | Submit to Del.icio.us | Submit to StumbleUpon

Posted in data center, grid, multicore, software development, Web 2.0 | 2 Comments »