Treat Your Customer As A Business

This is an attempt at making requirements elicitation more efficient and to help get the bigger picture. Software, whether it is explicitly said or not, makes an impact on the business it is being used in. Value of the software is driven by that magic number provided by the Return On Investment (ROI). So, even if the customer is an individual treat him/her as a business. This can bring out the standing and significance of the software in the business.

What business are we talking about?

A software is typically looked at as a solution to a problem. This problem lies in its own problem domain which lies in the business. The business involves much more than your customer. It involves your customer’s customers, your customer’s vendors, shareholders, other stakeholders and of course your customer’s competitors. A business also plays are role in the entire supply chain. A business interacts with its customers, interacts with other businesses, probably with customers of its competitors. A business is a system with other subsystems in it, in which people are involved. Any software, whatever its scope, used in any part of any subsystem has the potential of making an impact on the entire system and eventually making an impact on the supply chain. If the software does not make a difference to the entire system, then why invest in it? Accounting department of a company can want an accounting software. But if using it does not affect the business of the company, is it really useful? Meaning of usefullness can change when you consider this business.

The business gets its ROI only when it can leverage the software to improve its standing in the entire supply chain. This can be direct or indirect. This business is a different animal than your customer. It is affected by more factors, it runs under more restrictions and it also affects more factors. To be able to get a handle on these factors, it is imperative to understand and treat your customer as a business.

What factors are we talking about?

Business, being a generic term, lets look at its generic factors.

Localized Optimization

The software affects the peripheral businesses or subsystems, along with the problem it is supposed to solve. A manufacturing unit can improve efficiency of the production department, however, this efficiency affect the business only if it propagates through the delivery systems. Sometimes, an improved production department can stock up the inventory system which can turn into a cost centre. The production efficiency is also only as good as the efficiency of the business providing the raw materials. If this is realised earlier in the stage appropriate solutions can be identified for the possible problems caused by localized optimization.

The real benefit lies in overal optimization, which looks at the bigger picture and finds solution in the bigger picture. This factor can help us in tying features of the software to benefits to the business, without the middlemen of departments or localized cells. Somehwere there also lies the answer for ROI.

Current Investment

A business inherently involves people. With people come their skillsets, their ability to learn and their questions. Software is not only about development, it is also about training, it is about making the users use the software in a right way. This can happen only if their skillsets are considered. The business perspective highlights this factor which is missed a lot of times.

People are a form of current investments. There can be many others like using existing real estate, expertise and even softwares. A software initiative can consider to use them instead of requiring new investments.

Growth and Dynamics

A business wants to grow, wants to scale up, wants to do more things. The software should not be an impediment. There is no way of predicting future requirements, but the software design can include provisions for growth and scalability. Website for a newspaper, that has a thousand readers today, but expects five thousand in future, should be able to handle this scalability. An overhaul of the website for this purpose can turn about to be too expensive. This can be achieved by querying the roadmap or vision or goals of the business.

Restrictions

Last but not the least, a business operates under a variety of restrictions. Timelines, financial budgets and even the market trends factor into the various tasks that a business carries out. These restrictions percolate to the software initiative. Eventually, each of the restrictions on the software project are born out of some real-life business restriction. This realization can help us understand the impact of breaking any one of them. It can make us look for a better solution that can comply with all the restrictions. If complying with all is not possible, it can at least give us time to prepare for the eventuality.

Still Be Personal

Treating the customer as a business sounds impersonal. Being personal does not mean involving personal problems, but giving personal attention to the customer. Labelling the customer in a category of other customers and giving a generic treatment is impersonal. Every customer, every business and every project is different. Realizing this, treating them different and giving them personalized solutions is being personal, and this can happen only when you can deliver something that brings in positive results for the entire business. And this can happen only when you treat your customer, not as an individual, not as a group, but as a business.

Technorati tags:

Copyright Abhijit Nadgouda.

A Good Developer

Martin Fowler at ThoughtWorks says:

When someone is looking at what makes up a top-class enterprise software developer, often the conversation may turn to knowledge of frameworks and languages, or perhaps the ability to understand complicated algorithms and data structures. For me, one of the most important traits in a programmer, or indeed in a development team, is something that I’ll call Customer Affinity. This is the interest and closeness that the developers have in the business problem that the software is addressing, and in the people who live in that business world.

Bingo! The critical thing to realise is that software development is less about the software and more about the customer and his/her business. No amount of technical expertise will make the software work if the workings of the underlying business are not understood. Customer Affinity is about working close with the customer to understand the problem. And this creates the need for agility in the software development.

Business is a multi-dimensional entity, which is affected by multiple factors. It becomes imperative to discuss with the customer first hand to comprehend something like this and then automate it. Requirements gathering is not as much about interviews as it is about discussions. Interview is inherently a question-answer session, whereas a business, and hence software development is a field where you can have multiple answers to a question from different perspectives. Selecting the best one is an effort to talk to all the stakeholders involved, bring them on a common ground and then discuss with them. Like Martin mentions, most of the times the developer learns about the business by collaborating with the domain experts. In some cases a software developer ends up contributing a feature to the solution. An example of this is during a project of article management, the feature of related articles was something that came from us, the software developers.

The popular reason I have seen for this to not happen is that the software developer is too scared to talk non-technology with the customer, and the customer to talk technology. The ideal thing would be if both of them discuss the solution. Isn’t it the solution that we are really looking for? Discuss the solution, and let the expert handle the details of corresponding domains.

The developer should also be able to rationalise the requirements and then justify the design against them. At the end of the day, the software developer should be able to solve the problems with the designed software. I have seen lot of designs fail when they cannot assign purpose to the design. The best way to do this is a direct customer developer interaction at various levels and at multiple times during the software development project.

It is equally important that the customers realise that a customer cannot just wash off hands from the project after providing information. The customers should identify their problems, but also keep an open mind in the discussios and expect contribution from the other side of the table.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Web, JavaScript And Security

JavaScript is now main stream, thanks to the popularity and extensive acceptance of AJAX. In fact, AJAX is considered to be a core part of Web 2.0.

Acceptance of a technology by the industry has been a subject of its scanning under the security microscope, which has caused delays in accepting new things. JavaScript seemed to follow the same road, unless AJAX came around. AJAX gives this wonderful capability of behind-the-scenes requests to keep the web page dynamic, and make it more userfriendly and attractive to the user.

JavaScript has matured, however, not its security model. JavaScript opens doors to browser-based attacks. This may sound as the same old crib against scripting, but delve a little more in the side-channel attacks and the real danger surfaces:

“We have discovered a technique to scan a network, fingerprint all the Web-enabled devices found and send attacks or commands to those devices,” said Billy Hoffman, lead engineer at Web security specialist SPI Dynamics. “This technique can scan networks protected behind firewalls such as corporate networks.”

The popular mode of attacks today is by exploiting the different browser vulnerabilties. But, JavaScript can now get inside your network. Once inside the network JavaScript can attack any IP enabled device, including server, routers or printers. This is no more limited to the user’s machine, the danger expands to the entire network, including the corporate ones. Along with the Web 2.0, these attack strategies too will mature and the new websites can end up being haven for the hackers end up in another cat and mouse game.

The good thing about seamless integration with scripting turns into evil as the user will never know if his/her machine or network has been attacked or not. Unless, the user is knowledgable enough to set the security to the right level. Every computer user cannot be expected of knowing the JavaScript vulnerabilities or keep his/her antennas on for staying alert to JavaScript problems. It will beat out the productivity, which is the ultimate purpose of using computers.

Security makes it difficult

Various new web frameworks have come up which allow easy AJAX integration and build sites quickly. However, if the different vulnerabilities are considered, it is not easy any more. Consider the cross-site scripting, cross-zone scripting or the new dangers of JavaScript.

Security does not figure in many applications as one of the primary requirements. Either the client is not very interested or even if i is considered its cost might turn it into a good-to-have feature. Many a times, a project starts with a reduced scope where the security is not urgent and is ignored. However, the project evolves with time and then it is more difficult and expensive to make it secure. Today, Web 2.0 is headed that way.

Solutions?

Disabling JavaScript is the instant reactive solution to this problem, however it not practical. Today scripting is ubiquitous. The solution lies in preventing hacks not avoiding scripting. Incorporating security in the JavaScript design involves changing its model which entails changing almost every web application today which might take time. The solution has to be a two-way approach – a policy based solution and an effort to improve scripting environments.

Clients, designers, developers, browsers – the whole industry should accept policy based decisions to avoid hacking. It would be perfect if there would be a way of differentiating between good-intentioned and malicious code. Maybe there can be certifications to certify non-malicious code. Ted Dziuba presents a novel approach, though a little critical, by differentiating between a document and an application.

Indeed, JavaScript is useful when the main purpose of your work is an application. When you are presenting information, however, there should be no JavaScript between the user and that information. As I said earlier: we as developers have an obligation to the rest of the internet to classify our work as either document or application. So, the next time you think that having your entire web site as one page with AJAX controls, please, think of the crawlers.

Software creators should focus on security along with the quick and easy rush. Make the web site secure and safe along with making it dynamic, interactive and flashy.

The industry needs to hold back a bit, focus on the JavaScript vulenrabilities, prepare for it and then get gung-ho about it.

Technorati tags: , , , , ,

Copyright Abhijit Nadgouda.

Design Efficiency

Aza Raskin at Humanized has written an interesting article about design efficiency. He provides a quantitative way of measuring efficiency of the design.

Of course, efficiency cannot be absolute, but it is an indication enough.

The most important property of efficiency is that it lets you know how you are doing in the grand scope of things. If an engine has an efficiency of 10%, you know you can do a lot better. And if an engine has an efficiency of 98%, no matter how brilliantly you design, you won’t be able to improve it much.

Efficiency lets you know when you can stop looking for a better design.

Efficiency can tell you when you need a new inspiration.

A benefit of the efficiency is the focus on big picture and to be able to consider all the different aspects, and consciously ignore the ones that don’t matter. It is extremely important to consider only the factors that fall within the scope, otherwise it leads to the wrong direction or a wastage of effort. It is also important to measure the efficiency from the user’s perspective.

Aza includes on the quirks I love to hate – the desktop:

The Desktop.

Think about it: if you want to write a letter, how much of the letter do you get written on the Desktop? None. If you want to look something up in Wikipedia, how much of the searching do you get done on the Desktop? None. If you want to perform a calculation, how many numbers get crunched on the Desktop? None!

The time you spend fiddling with your Desktop to get where you need to go to get your work done is entirely wasted. You get no work done on the Desktop. It has an efficiency of 0%.

Clearly, there is a lot of room for improvement on the Desktop. A lot. We think we have a solution so keep your eyes peeled next month.

In my opinion, the desktop should play the role of an interface to the computer. Whether we are dealing with applications or activities is something that the desktop should convey and should be customizable according to the user’s expertise.

Efficiency is important, it determines how much to design or sometimes enables innovations that break the conventional ways and leads the pack.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Software Development Is Like Running A Restaurant

Software development is alien to a lot of people and explaining it in technical terms really makes it worse. So, we use metaphors. Lidor Wyssocky says it is like a broken telephone. And there have been many more attempts, to compare it with the construction industry with similar roles – architect, designer, developer (?) or manufacturing. Here is my attempt.

Software Development Is Like Running A Restaurant

This is the closest metaphor I can find today. To serve the customer that satisfies his/her needs, to provide tasty servings that are unique enough to make you standout but still within the realms of expected quality and standards is what we both do. It requires a delicate balance of creativity, engineering, understanding of the customer’s needs and other constraints like time and budget.

The waiter has to not only provide the menu but also gather what is it that the customer is looking for. Most of the times the customer does not what to order because he is not familiar with the culinary skills. It is upto the waiter to get the information, and help the customer choose a course. The course is split into parts and include the condiments like wine or starters are part of the order, they are the ones that complete the experience.

Once the order is taken, it has to be given to the kitchen so that the chefs and use their knowledge and skills to work on the order and create something that will satisfy the customer. There should be good information flow and collaboration between the dining area and the kitchen so much so that the customer feels that they are one and the same. The chefs have to be careful to select the right ingredients and the right combinations and the right proportions. Any change in this will cause a change in experience to the customer. However, the chefs cannot have all the time in the world, they have to serve before the customer gets frustrated waiting for the food. If the customer is hungry it might call for a different order or an expedited preparation. The decision involves not only the chefs’ skills but also the needs and constraints of the customer.

In the kitchen it is a different ball game for the chef. He has to design the dish, along with managing and motivating his team to complete the dish in time with a certain quality. This calls for samplers, tasting (or testing), good people management and good communication. Typically the kitchen ends up serving more than one customers which requires good estimation and scheduling skills.

Sometimes it makes sense for the chef himself to come up and talk to the customer. A lot of times problems raise their ugly head, like lack of seating or local problems like loss of electricity or disasters in the kitchen. The restaurant needs to have a good manager who can handle these situations and keep the customer abreast. A good restaurant will like to take the customer’s feedback and suggestions, and factor them in their improvement. Unless this experience is good, the customer is not going to revisit the restaurant or suggest it to his colleagues or friends.

Last but not the least, it is important for the restaurant to realise that every customer is unique. The same course need not satisfy all the customers, the restaurant has to consider and treat every customer individually and serve individually.

All this has to happen while making sure that the customer does not feel that he has been handed an expensive deal. The restaurant should still keep making money, and hopefully good profit so that some of it goes back in improvements of the restaurant and stay updated to the trends. The restaurant has to, in the background, make sure to manage the raw materials and manage the vendors.

And you see all kinds of restaurants – from the five star ones where there is a hierarchy of waiters to the ones who are affiliated to hotels and lodges to the three star ones, the Thai, Italian, Mexican and such specialized ones to the mass caterers to the diners to the ones that are part of a food court in the malls to the ones who give take-aways to the ones on stalls on the road.

It Is Still A Metaphor

Having said all this, running a restaurant is still a metaphor. The biggest difference is that the software development is about automation that is expected to serve for a longer time. This is what makes it complex, it is expected to serve for a time in which the customer’s needs and requirements keep changing.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Interview With Usability Guru

Usability guru Jakob Nielsen was interviewed (via Ajaxian) on usability and its relation to advertising.

One of the things that come out of it are the applications of AJAX.

It’s important to remember that most web sites are not used repeatedly. Usually, users will visit a given page only once. This means that the efficiency of any given operation takes a back seat to the discoverability and learnability of the feature. Therefore, interaction techniques like drag-and-drop should almost never be used on web sites. Instead, focus on showing a few important features and making them accessible through a single click on a simple link or button.

Some business sites that are used repeatedly include features for approximating software applications. Online banking comes to mind, and I can easily envision a design that enables the user to see the front or back of a check through an AJAX technique on the account statement page, instead of going to a new page.

Do we simplify or in fact complicate the interaction by adding advanced features? This is a question to consider whenever any feature is being implemented. Ideally, any feature should be implemented such that it supports maximum number of platforms and browsers without any third party plugins.

He also mentions the classic problem of doing technology for technology’s sake. It is important to realise that the software being developed is for the customer and no one else.

Remember: just because you love technology and advanced features, it doesn’t mean that your customers do. They just want to get in and out without worrying about your web site. So take it easy on the features.

I agree in entirety that adding features or programming tricks turn into just gimmicks if they are not targeted to be used. One of the best ways of identifying the required features is to identify their usage – who, why, how and when. If there are concrete answers to these questions that feature becomes an important one. Rest fall in the category of gimmicks. Every Web 2.0 company talks about AJAX today, but how many talk about using it for improving the website?

He also talks about usability and conversion rates. Usability is an important factor, it makes the user comfortable and that drives traffic. Advertising can get a user to the website, however the conversion to a frequent user will depend on the content and how usable the website is to consume the content.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Simplicity and Side Effects

Alex Bundardzic has written a nice piece on achieving simplicty when developing software. He also points to the post on 37 signals on similar lines. Like other times, I have commented on Alex’s post, but later I thought that this topic warrented a post here.

What About Flexibility?

However I feel it is a incomplete without its possible side effects. The biggest one being lesser flexibility. Of course flexibility itself can be the evil sometimes, but design of any software is (or should be) done with enough flexibility. One of the most classic divisions in the Linux world is over Gnome ‘s simplicity and KDE‘s flexibility. Another instance is the popular messenger gaim opting to reduce the number of preferences to make it simple.

Reducing the necessary flexibility can kill the application and sometimes its usability. There are logical sets of customization units that can need to be equally flexible, e.g., to let the user select a font, the change of typeface, font size and the decoration all has to be provided in a word processor. Howerver, this flexibility might not be necessary for writing posts on a blog as the presentation is controlled by the theme.

Solution?

What is required is to keep a balance between enough flexibility and possible simplicity (through usability). Beyond this balance these folks are ready to wage a war with each other. One of the ways I like to achieve this balance, in case of preferences, is to provide default values. Allow the user to make fewer choices by providing default values for things (s)he does not care about. So that the other (s)he will have more or lesser choice. Using the combination of flexibility and default values you can provide different levels of choices to different users.

Another way can be to provide themes of preferences that users can choose. Something similar to desktop themes or blog templates and themes. The user profiles should be used to identify the different combinations of choices to package as a theme.

Documentation A Must

I think this is the biggest effort cost of providing flexibility. Without supporting documentation it is just another bundle of controls and dialogs for the user. Usable and extensive help can provide the necessary education to the user about the application.

I am a believer of the Less Is More paradigm, but it is imperative to decide on how much less. This will by and large be dependent on the user profiles the application is expected to serve. Over the long term a software with the right formula of flexibility, simplicity and functionality will be successful. However, it is important to see that the formula will not be the same for every project, it will vary and will depend on lots of factors. It should result in a software as simple as possible with enough flexibility to provide the expected functionality.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Requirements Are Important

“Requirements are for you, not for me!”, blasts the CEO at the software provider. “Don’t waste my time on it, and don’t charge me for it. Just give me what I want.”, he continues while walking out of the meeting. Well, not exactly, but I have come across this more than just a couple of times.

Most of the times businesses decide that they want to start using a software because they think that it will solve their problems. However, the problems are only the symptoms. It is important to gather more information so that the diagnosis can be successful and the right cure can be proposed. Especially in today’s age, softwares are not just adopted by businesses, softwares become integral to execution of the business processes. However, the software can provide the perceived Return On Investment (ROI) only if the automation targets not the problems, but the root causes of these problems. To be able to do that it is imperative to gather more information – which is the requirements gathering.

Feature-driven Selection

Usually the decision to use a software is reactive and not proactive. This ends up being a deadline-was-yesterday project and software tools selected are mostly feature driven and not requirements driven. As an example, there are many Content Management Systems (CMSs) available today provide comparable features. Just because a CMS provides an article management system, it does not mean that it can be applied to every newspaper publications. There are various factors within the domain of article management system like workflow, flexibility of the workflow, its maintainability and more that determine the right choice.

Feature driven selection usually ends up in either the tool not being flexible enough to satisfy the requirements. Or the customization costs are so high that the budget overflows. In either case, it is termed as a failure of software engineering. The success of software engineering starts by idenfying the requirements.

As Content Management author and consultant Gerry McGovern says, “I’ve seen so many organisations that have gotten burned because they didn’t spend the time to really figure out what they wanted.”

Requirements Represent Your Business

No business is similar to another, nor should be the solution. Two businesses can work in the same domain, be of same size and be located in the same geographical area. They are still different, because there are simply too many factors that profile the business. It includes the business vision, the staff and its skillset, the budget and probably many more. For the same reason, a software solution applicable to one business cannot be copied and pasted onto another. If it is, then it will not provide the maximum returns, sometimes making it a complete failure.

Requirements represent your business and domain and make it unique. Only the requirements identification can provide what the business needs and in effect the right solutions.

Requirements identify two distinct pieces of information that provide an answer to the question – What to do?

  • the existing processes and system of the business (as-is)
  • the future processes and system (to-be) that encompasses the solution

The software engineering is an exercise of transition from the as-is model to the to-be model and provide the solution. If the as-is and to-be models are not identified then the software project can end up in a wild goose chase.

Requirements are usually born out of two sources:

The Business Vision, Business Rules and Constraints

These are usually long-term requirements which are defined when a business is established. Businesses have vision and rules that work as guiding principles and in the process impose a way of working. The business constraints are more distributed in nature, and can change with time. Some examples of such requirements are:

  • The business has to target markets in multiple countries to be able to achieve its vision.
  • The business is geographically distributed and requires communication tools within the branches.

Current Problems

These requirements represent the current situation, and hence the requirements can be short-termed. However, they usually indicate towards some long term root causes. In such cases it is important to look beyond and identify why the current problems exist. Usually the impact is on the underlying processes.

  • The changes in the company are so dynamic today that we are not able to communicate all of them to our customers, other branches or other stakeholders.
  • The maintenance work going on certain machines makes it difficult to complete the work in the scheduled time. Do we need to change the schedule?

These point towards certain underlying issues. This may be because the environmental factors have changed, and the business has to react effectively. It is also possible that these problems are being caused by certain constraints and breaking these constraints might provide the solution.

Future Requirements

The irony of requirements is that we try to specify them, but they change with time. So does the business, and the rules and possibly the constraints. It is important to realise that businesses are dynamic and solutions should be flexible enough to accomodate them. It is not possible to envision everything, but reflecting on possibilities in the near future can help decide flexibility of the software tool that should be used.

A Piece Of Software Is Not A Solution In Itself

A software package itself is not a solution. The solution is in its application to the business and its appropriate usage. If there are problems in the underlying processes, then only the software will not help. The real solution might involve Business Process Re-engineering so that the root cause is eliminated. However it is difficult to determine if the requirements and the root causes are not identified.

There are various ways of requirements gathering but that will be another post in itself. Requirements are not for the software, but for the business itself. Only after defining the requirements can the solution be defined. Otherwise it might head for just another failed software project.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Adaptive Websites – The Future Of Web

Web 2.0 has ushered in a new era of democratic usage of the Web. It is more focused on the user than its earlier version. This has pushed much more information, in many more formats, on the Web.

The Problem

Web is a major source of information today. However, it is also a source of information overload. It is not only the user generated content, but also professional publications like newspapers and magazines taking the online route. In addition to the stiff competition in the online businesses, Web is continuously changing and adapting to the demand by diverse users to display more relevant content. What is the best way to handle this? The answer lies in the not frequently mentioned concept of Adaptive Websites.

The First Bite

Carolyn Wei explains the concept by using Amazon.com as an example.

Adaptive websites use data provided by users and monitor their actions on the website to customize the content and layout that will interest the user, e.g., Lonely Planet could display more relevant weekend getaways by considering the user’s location or by understanding the typesof getaways prefered.

No, the My Yahoo! like portals are not adaptive websites, they allow the user to personalize content, but the onus is on the user. A website, by being adaptive, learns from its usage, learns from user’s experiences and adapts itself. The biggest difference in the two is the ability to learn and adapt. The result can transform the view including changes in the layout along with the content.

The Meal

To be able to serve a user, adaptive websites build the user information within themselves, called user models. The user models depend on two types of information:

  • information provided by the user voluntarily
  • information gathered by the website over a period of time of usage

The earlier one might comprise age, location, gender, profession or other deterministic factors, whereas the latter is more of an experience out of multiple interactions with the website. Users leave breadcrumbs of their visits, which can used to build information about their interests or likes. Sometimes the navigation options used by them can provide more information about related content or popular content.

However, it is difficult to track every single user like this. Adaptive websites use the technique of clustering to group users and build user models for that. Whenever a user visits the website, the cluster is identified and the corresponding user model is loaded.

To keep on improving the user model, continuous monitoring, data logging and mining of the log is required, which can affect the performance. It is possible that the user does not provide accurate voluntary information, in which case the adaptation will fail. It is therefore important that the user is explicitly told about significance of the information.

To think of it, this concept is applied in lot of places – some websites display the appropriate language depending on my language preference or the IP address in the HTTP header (internationalization and localization). Rojo, a feed reader, asks the user about his/her interests and provides the popular feeds in those interest areas. However this concept has to be applied to a much wider aspect of the website – its design and information architecture.

The Digest

Today, with online overtaking print, blogs being used for businesses and networking, and websites getting as common as the common man, it is important that the websites now start understanding the users rather than just recording them. The current path leads to Adaptive Websites which will adapt themselves for the user.

Technorati tags: , , ,

Copyright Abhijit Nadgouda.

Is Internet Fueling Collectivism?

An amazing essay by Jaron Lanier about Digital Maoism delves into the behavior of collectivism and whether the Internet Age is fueling it. However, the core subject is much deeper than the digital world encouraging mob madness. It is about whether we can benefit from groupism and Wisdom of Crowds, and if so when.

As Lanier mentions, this collectivism is seen in many places, through participation of individuals. The American Idol (or Indian Idol), elections, Wikipedia and stock markets are some examples. However, there is primary difference in Wikipedia and the American Idol model. Wikipedia nurtures objective factual information, as against subjective opinions. The fact remains the fact and its truth is not influenced by who has written about it or how many have written about it. The strength of a group can influence how much information is available. What Wikipedia has done is make this immense information available by using a open group of authors rather than a closed one. If a piece of information is not accurate or right, it can be re-edited to reflect the truth. In other words, inaccurate information by authors is corrected by its accurate version. They are written by humans, errors are possible and will be corrected. However, the probability of correction improves with the number of people involved. It is not chaos, it is a system where inaccurate information is replaced by the accurate one which can be verified because of the objectiveness.

Wikipedia, an aggregator, does not mean that the individual authorities are undermined. They still are respected and are read. However, Wikipedia serves just as a singular storage of information and not is not intelligent in itself. But it serves as one of the best references to have.

On the other hand, American Idol model works on gathering votes based on subjective opinions and judgements from the common man. The tragedy is that people who do not have enough knowledge can not only participate but their vote gets counted, whether any other knowledgable person votes or not. Usually, a minority of the population is an expert on any subject. However, with votes being counted, the majority is always going to overrule the minority thereby throwing away the argument for merit. Surprisingly, this model has been replicated in many countries and even there the model is raking in money, which seems to be the primary goal. I haven’t seen the Indian Idols chosen improving their musical or performance abilities. However, the average talent that comes out of the model has improved, now there are more performers have exposure than before. The average beats the best!

While I agree that American Idol probably has the best business model and it brilliantly exploits the mob mentality, it is not a good example of collectivism bringing out the best. If I say, I don’t like a certain painting, that does not mean that the painting is not good, it is my subjective opinion, and the painting itself should not judged by it. A couple of years later I might change my perception and take a liking to the same artifact.

And there is also the blogosphere. Isn’t it an another form of collectivism? What blogosphere, as a whole, does is bring a subject in view of many others. Frankly, I would not have read this essay if it was not for the blogosphere. However, this neither means that the subject is important nor does it say whose opinions are important. It is entirely the onus of the individual to act and how to act on the information. This probably applies even in the stock market. The mob mania causes spikes or trenches in the sensex graph, but it is momentary. Whether to react to it or not will depend on the individual investor.

Elections are probably true processes of democratic participation by individuals to form a collective voice. However, there are multiple instances that they have completely failed. They have failed, not because collectivism does not work here, but maybe because the citizens did not have enough information, or enough did not participate or that they were completely rigged. However, this is another example, where the total number of votes might not bring out the best.

While discussing with a friend, what also came up was that not only the subjective opinion but also aspect of the subject might matter sometimes. In a software, the users opinions count a lot when its usability is being tested. I wonder how it will work if they are asked about the software engineering or the software process used for it. However, I see it works for usability as it is targetted towards the users and hence they are the best candidates for opinions on it. In this case, the proportion of the mass that reacted or opined is important.

Now to the more resident issue – is the internet fueling collectivism? We are seeing more and more aggregator models being used by businesses. The aggregator is a matter of convenience rather than intelligence. For example, it is convenient to read everything in one single place. Why they have worked in business models because they supply convenience, which is in demand by the users. If you look at Slashdot, it has been brilliant in reporting news that were not available in many places earlier. Sometimes even the discussions provide lot of value, but it never tries to snatch the credit or highlight from the original article itself. The aggregator model can build intelligence over and above the one provided by an individual, which is not harmful. In fact, collaboration between groups of people has also led to generative internet and community marketing as in case of Mozilla Firefox.

Whether collectivism is good or not, whether it works or not is more dependent on the subject it is applied for, and what it is used for. It, by itself, is not good or bad, its usage is. By nature, even this post is again just another opinion of an individual, probably even a subjective opinion and should not be counted as a vote.

Technorati tags: , , ,

Copyright Abhijit Nadgouda.

Follow

Get every new post delivered to your Inbox.