Skip to main content

Social Networks: The power of symmetric relationships

A recent post on the blog by Joshua Porter, highlights the difference between relationships on Facebook and those on Twitter. Essentially on Facebook, relationships are made when a request for friendship is accepted by a person, adding both on each others contact list. If in time one person removes the other, the relationship is broken as the other will notice they are unable to contact the former friend without sending another friend request. This is a symmetrical relationship as it goes both ways, the other type of relationship is the assymetrical type that Twitter uses, you can follow some one without them following you, this allows people to expand their follow network without having to wait for confirmed friend requests, similarly others can follow you without requiring explicit confirmation. Essentially the default nature of Twitter conversations is as a broadcast to ALL that care to listen, where as with Facebook, the broadcast is to those who reciprocally wish to "hear" one another.

The argument is made in the post that the assymetric model is better for Facebook to persue because of the ability to allow users to rapidly expand their social network without requiring confirmations. I agree that in a social network such as Twitter it is better, as the broadcast model is best served but there are some important constraints architecturally to the choices. Twitter's broadcast to any , assymetric model makes the process of updating followers significantly more tedious than for a symmetric model which has a relatively limited number of managed relationships. The Twitter API showed the weakness of the need to propagate so many updates to so many followers per tweet in the early days when it had many outages. As it grew it stuttered under the sudden spikes on the architecture when tweet floods propagated through the system. Even today, the site still experiences "the whale" when load spikes. The real time nature of Twitter that makes it so valuable as a means of notifying "who ever is listening" also exerts crushing demands on the architecture. The assymetrical model allows fast scaling of a users social network but exacts the cost from the fragile infrastructure of Twitter. A recent architectural redesign has mitigated some of the issues but as it continues to grow , the exponential nature of broadcasting assymetrically will continue to dog the infrastructure. Conversely, Facebooks symmetrical model is much less prone to the effect of spikes as users send status updates. The scope of the updates is limited to their friends , which tend to be significantly smaller than the number of followers on twitter. Recently the addition of "Pages" replicates the asymmetrical model of Twiiter. Facebook is much bigger than Twitter and has over all more load but it also has a much larger infrastructure of nodes distributed across the globe to handle the load. However, the usefulness of assymetric networks varies with the social network. In a business that has an intranet that allows employees from different departments to collaborate, having an assymetrical model for some users and symmetrical model for others could be very beneficial. For example, for the members of various departments in the company , the social network should be restricted only to the members of those departments. Sales, Tech, Biz Dev...etc. This ensures that the conversations had between members are relevant to the department they share. However, the ability to have assymetrical communication between say the CEO and the rest of the company (regardless of their department) should also be possible. In a business social network a hybrid of the two models, controlled by relevant security is ideal. The goal in this case is not to reach as many people as possible but on the one level (department) reach specific people sharing work related functions, and on another it is reaching everyone in the company. By granting selective ability to broadcast events to these different users based on the position of the sender in the company, greater utility can be made by the business of the service. Allowing the relationship types that are most efficient for the networks that arise in business is important and will vary from business to business. So far, neither Facebook or Twitter allow this functionality for a business...allowing the business to control the social networks within its virtual walls by weaving the use of symmetric and assymetric forms and tying the interactions under a secure umbrella. The site provides this secure combination of network types and allows businesses to deploy and manage them easily using what are called TimeLine Events. I'll be revealing more on TimeLines and how they facilitate efficient business networks in subsequent posts.


Popular posts from this blog

On the idea of "world wide mush" resulting from "open" development models

A recent article posted in the Wall Street Journal posits that the collectivization of various types of goods or services created by the internet is long term a damaging trend for human societies.

I think that the author misses truths that have been in place that show that collectivization is not a process that started with the internet but has been with us since we started inventing things.

It seems that Mr. Lanier is not properly defining the contexts under which different problems can benefit or suffer from collectivization. He speaks in general terms of the loss of the potential for creators to extract profit from their work but misses that this is and was true of human civilization since we first picked up a rock to use as a crude hammer. New things make old things obsolete and people MUST adapt to what is displaced (be it a former human performance of that task or use of an older product) so as to main…

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

Live Coding Exercises: How NOT to hire potentially Brilliant Engineers.

I've intimated this view before but, I abhor "live coding" exercises for engineering interviews and will never have them as part of any interview process I conduct. They are simply unrealistic to real world engineering in every possible way, they only test familiarity (or luck) with a tiny subset of solution methods to a specif subset of problems...that you either "nail" or get spectacularly wrong depending on who is observing you.

They are mostly entirely unfair to the candidate on top of the pressure of having a gun under them while coding, only in the most extreme cases is coding under the gun and that's just competitions where the code is far from real world engineering why test for general coding ability with such tests?? Stupid.

I posit, it is significantly more effective to see examples of a candidates finished working code in the form of a project or projects they've created. How long it took some one to get some uber algorithm work…