Manish Rathi’s Blog

Well, if you were in India last week you could not have missed the big news - the famous Apple iPhone has finally made its debut in India. Well, I mean atleast officially. This came after years of its debut worldwide. This after half the Indian population had already sneaked in the iPhone from all the surrounding countries. And this after even the endangered guerrillas in the Congo basin may have started owning one. So, Mr. Steve Jobs, welcome to India! Glad that you could finally find this country on the map.

Before I delve more into this post - please don’t get me wrong here. I like Apple and have always admired their products. There may be two thoughts about the quality of their products, however no one can deny they have always been different from their peers and have always stretched the boundaries of innovation. I own some of their products and long to own some more too. My only challenge with them is that I have always believed that Apple has always made suckers out of the consumers. And as consumers the unfortunate thing is that we have allowed Apple to do that honor on us!

To prove my point - take a look at the price range of the iPhones which were rolled out in India. It is somewhere around 35,000 Indian Rupees (this is nearly about 800 USD) with a forced service plan. The same phone in US, if I am not wrong, costs around 200 USD. I am assuming that most of the iPhones are manufactured somewhere in and around China. So it should be relatively cheaper to transport iPhones from there to India.

My argument here is not about India (or any other similar country) can afford it or not from an economic sense. (I personally believe that the count of people in India who can afford iPhone is much bigger than the population of United States). Also, I believe a lot in Capitalism where the seller should be able to decide their own price. Same thing holds true for the Consumers who can decide for themselves if they want to accept or reject the same price. However, my argument here is about what kind of view does Apple (and its associated business partners) have about Consumers in countries like India.

Here is my simple anology. I tried comparing the ‘affordability factor‘ of iPhone in US and India. A fresh under-graduate software engineer typically makes about 4500 USD/month in United States. (I am being location agnostic here). If he/she were to buy iPhone in US today that would be about 5% of his/her monthly salary - assuming the cost of iPhone to be around 200 USD. Counter-part of the same software engineer in India typically makes about 50000 Indian rupees. If he/she were to buy the same iPhone in India today at the cost of 35000 Indian rupees, that would be about 70% of his/her monthly salary. The difference between 5% and 70% is very telling here.

Now, if iPhones were to sell at the same price as it is sold in US and even if Apple (or its partners) decided to make a 20% markup on that - the same iPhone would be 20% of the monthly salary of the Indian Software Engineer. The difference between 5% and 20% between the two counterparts is reasonable IMO. However, difference between 5% and 70% says a lot on how Apple views the same consumer segment in two different geographies.

Once again, I am not trying to be a populist out here to say that Apple should do concessions. Indian consumers, IMHO, have a powerful buying capacity. However, my opinion is that they are getting sucked in a big scam here.

On the day of the launch, the providers who launched iPhone in India proudly published the photograph of a smiling young lady who they claimed to be the proud first owner of the iPhone. If I were in the shoes of that young lady today, I am not sure if I would be feeling good about getting duped as a ’sucker’.

Thoughts and fires are most welcome!

It has been some time since I have blogged. As usual, hectic work schedule over the last month took the toll on my blogging habits. Not that I am complaining about the same. The last month went into some wonderful work. On a personal front, it was an enriching experience for me to work in a high profile environment and to look at things from a completely different perspective. It also was a big validation of the GlobalLogic Version 1.0 Offering which we have put together recently and now have taken it to a completely different level. The ability of the entire team to come together to understand, comb through the issues, and deliver was very fulfilling to see.

While I will not go through the details of the project, the key challenge for us as a team was to help a high profile client of ours to go through a series of planning activities to convert an idea to a product and then take the product to form the base of a successful new organization. Envisioning a concept getting converted into a real enterprise product is not a simple task. IMO, almost most of the times how well one executes the tasks associated with product development supersedes the brilliance of the idea itself. Product Development today is an ardent task in daily-changing business scenarios and tough competition. In addition to that one has to hash through the combinatorics of available go-to-market options, product visualization, technologies, competition, risks, and partnerships and come up with a clear strategy. This requires broad and experienced heads to come together and work around evolving the best plan forward. This is where my team comes in. Our work starts with understanding what is driving our client to his/her vision; go through the multiple dimensions of issues; and come up with a prospective plan. There is typically no one single perfect plan to build a product. However, simply putting things in proper context and perspective can be of great value. Almost all our clients vouch for that. The main questions which we help them answer are -

• What are we trying to build?
• How will we build it?
• What is it going to take to build it?

It is not easy to answer these three questions to the highest degree of correctness. One has to put the past experience to work a great deal here. However, the biggest criterion here is how to make the plan Agile and Adaptive. That is the key.

Before I jump into this post, let me describe what I mean by Engineering Activity. An activity where knowledge of relevant science is applied to achieve the required result is an Engineering activity.

I was reading this paper titled “Large Limits to Software Estimates” (PDF link) by J. P. Lewis (published in ACM Software Engineering Notes,Vol 26, No. 4, July 2001). I am not much of a mathematical theorems person, so I skipped the initial few sections and came to the conclusions part. In the conclusion part, the author raises the question - “Should Software Estimation be called as Engineering?“. He argues that if we were to consider Software Estimation to be an engineering process, then litigation/conflicts should be a reasonable or acceptable outcome for incorrect estimations. If not, the author raises the questions associated with ethics in the software community - considering that so many estimates are ill-founded or bloated. The author also points to another article titled - “Are We Developers just liars or fools?” by Robert N. Charette. (If you are not ready to pay to ACM for this, here is a link to a similar article written by the same author.)

Before I jump into writing my thoughts on this one,  I wanted to point out to a quote from Hannah Arendt, a self-claimed German-Jewish political theorist, which I had read sometime back.

Promises are the uniquely human way of ordering the future, trying to make it predictable and reliable to the extent that this is humanly possible.

To come to think about it, software estimation is also about trying to make the future predictable and reliable. However, except probably the psychics, I am not sure how many of us would make a claim on predicting the future to the reliable extent. This brings to my next point.

Anyone who has been in this business, doing software estimation is one of the toughest job. If given a choice, most of us would probably prefer the “will call you when it is done” approach for communicating the estimates.  While I agree with J. P. Lewis that estimation should be based on sound engineering principles; however in reality that is rarely humanly possible in software business.

Most of the estimates today are based on past relative experience and gut feel of the individuals even if the functionality is broken down to the nearest function points. I am not saying this in any negative way. Almost all who have had some good relative experience in this business would realize the fact that software development is a process of gradual refinement. This is especially true in today’s world of internet-enabled mass-consumer products as compared to a decade back. We have to keep in mind that both the consumers and the producers of the software products are in the end human beings. IMO, it is hard to find human beings who know what exactly they want consistently. Because of this the software estimation process is going to remain fuzzy in the initial stages and typically gets better refined with the time. So Robert Charette’s argument that software industry should stop reporting incorrect estimates in order for it to be held up for respect and emulation is slightly naive in my humble opinion.

Software estimation should be treated for it really actually means. Dictionary meaning of estimation is “approximate calculation“. And the dictionary meaning of approximate is “nearly exact; not perfectly accurate or correct“. Estimates like in any other context should be treated as a guideline. All the trouble starts when it starts getting treated as a quote or as an actual quantitative number. I am personally of the opinion that estimates can never be challenged; only thing we can do is to help improve it.

So if I were to plagiarize Hannah Arendt’s quote mentioned above and apply it to software estimates, this is how it would read -

Promises Software Estimates are the uniquely human way of ordering the future, trying to make it predictable and reliable to the extent that this is humanly possible.

I would love to hear your thoughts or comments.

Came across this on snopes.com. The story of square watermelons invented by smart Japanese farmers to solve the space problem. I am not surprised this came from the Japanese! They are the best to come up with brilliant ideas when it is about coming up with solutions associated with the space crunch problem.

Probably this is the best invention after someone figured out to slice the bread and sell it .  I like my watermelon cold and chilled. However, the storage part of it has always been the main challenge. You have slice and dice it to keep it in the refrigerator for consumption over few days.

The price tag on these watermelons seems to be hefty right now. However, I am sure with demand it can be brought down. Other than the Japanese market, it seems that the square watermelons are also making its way to Canada this year.

Having worked with more than half-a-dozen start-ups now right from the early days, I have had the first-hand experience in seeing how critical the initial team formation step is. Not only the quality of the team mattered but also the timing associated with getting them together was critical too. Once the team gets in place, how soon the team ramps up with the mission and gets going is another hurdle the start-up/entrepreneur has to worry and cross.

Having seen it closely, many start-ups tend to miss out the after-effects of the Bruce Tuckman model of Group Evolution. Per Bruce Tuckman, any new team on a project typically goes through four stages of evolution before we see them performing as per the expectations set on them. These stages are inevitable and in some sense they are all necessary and happen in the same order.

1. Stage I - Forming: The first few weeks are spent in this mode when the team comes together. They are in the process of understanding what needs to be done but typically tend to remain and behave in an individualistic manner. The initial personalities of the individuals come to the fore in this stage.
2. Stage II - Storming: A slightly painful stage wherein individuals push forward their own ideas for consideration and tend to resist any group pressure.  Typically numerous conflicts arise at this stage because of different personalities, roles, and styles which can make things difficult for teams to work together. Depending on the maturity of the team, these stage can persist for weeks and months. Storming stage is however considered necessary for the growth of the team.
3. Stage III - Norming: This is the stage where the teams start putting their individualistic thoughts aside and become more keen in finding solutions by agreeing on guidelines, behaviors, methods, etc. Teams start trusting each other. Signs of increased motivation are visible in the team.
4. Stage IV - Performing: Again, depending on the maturity of the teams, only few teams would reach to this stage where the performance levels are optimal. Teams start functioning as a unit. They are focused on the common goal and work out decisions/conflicts using a more collaborative style.

Depending on the team size and complexity of the group structure, this evolution of group can take weeks and months. In my experience, only few of the start-ups can afford this and any mis-handling in these stages can be disasterous.

I have always believed that for most of the start-ups, the process of achieving their first goal is like playing in a limited-over cricket match. There is a limited quota of time; constrained number of resources; and steady influx of surprises/changes which they need to tackle. And I am talking about this from business perspective. In all this it is very tough for many start-ups to afford their team to go through the above stages. Imagine the eleven players - unknown to each other - going out to play a limited over cricket match and going through the stages above. This team cannot afford spending time in solving individual conflicts or formulating strategies or the game plan while they are on the pitch. The team needs to start scoring from pitch no. 1.

So if Tuckman’s theory is true and considering the limited options in front of the start-ups to afford what is described in this theory - what are the alternatives? Well, in a simple scenario if the start-ups can afford it, they should include this time as part of time-plan and cost. If not, there are other alternatives too.  I will talk about it in one of my future post.

A colleague of mine sent me this email today. He mentioned about the dilemma which one of his client was facing. I have pasted his email below (I have changed some of the names to respect the confidentiality)

Hi Manish,

I needed some help on projecting Agile as compared to water fall. PQR product is getting implemented at ABC and ABC’s project head Dorothy is facing some challenge in motivating her team to work in Agile way, especially when it comes to UAT. I think it’s becoming hard for her to convince that ABC’s users can continue part testing for features released in UAT. ABC’s user’s team is more comfortable doing QA when complete product is rolled out for UAT. This approach will hamper implementation dead line (before <Month> 08 end). She was looking from us some kind of presentation / stats which clearly explains benefits of Agile over Waterfall and give some stats (if possible) on failed big projects using waterfall and successful agile ones.

Can we get some stats / figures etc around this request?

Having been in similar situations in the past, I can certainly understand Dorothy’s challenge. While I did respond back to my colleague (please see below), I thought about posting this email as a blog post to see if any of the readers out there can help Dorothy with their experiences and metrics. Also, I am sure there would have been many in Dorothy’s shoes and wanted to find out what they did to overcome the challenge. Please feel free to add your experiences in the comments section below this post.

My response to my colleague -

Hello,

Software industry is littered with examples where the software failures (by failure I mean that it was not able to meet end-users needs) have occurred. However, most of the time it is very difficult to say that the failure occurred because of waterfall or agile or any other similar methodology. IMO, failures are always because of certain risks which could not be mitigated at the proper time. This article at the link below shows a survey results which lists why project failures have occurred in the past. When you look at these risks, it is fair to say that Agile Methodology is better equipped to mitigate these risks as compared to Waterfall.

http://www.bcs.org/server.php?show=ConWebDoc.19584

Coming to your point of metrics – I personally do not have the project failure/success metrics comparing Agile vs. Waterfall. I can certainly hypothetically speculate, however I do not think that is what Dorothy wants. If I can understand what she is trying to look for is to look for ways to mitigate the uncertainties associated with the implementation deadline. If she lists these risks down and plans to mitigate that, she will very clearly see and convince people that Agile is probably their best bet.

I am slightly going on a philosophical note here – unfortunately we engineers many a times fall into a debate of one vs. other – Agile vs. Waterfall, Java vs. .NET, and so on as if they were two religions. I think achieving the goals is important as compared to looking at the rewards associated with selecting one vs. the other.

While I do not have a ready presentation on Agile vs. Waterfall (there are plenty on internet though which you can point to though). However, I would be happy to show and explain how we (in GlobalLogic) do it in Agile if Dorothy is interested. Also, please do note that the way there is ‘bad waterfall’ there is ‘bad Agile’ also

Thanks

Manish….

As I said in my email, the success and failures of a project are typically not because of a particular methodology - but how the methodology helps to manage and mitigate the risks associated with any projects. There are good and bad implementation of all the methodologies out there. In my experience, it is not in the best-health of the project to get into the debate of goodness of one approach vs. the others. We should leave it to the ‘academicial-minded‘ to do that. The key is to take the best of all the approaches which would mitigate all the risks associated with the project.

I came across this post written by Kevin Barnes on Agile Processes. A slightly old post and I am not sure what exactly Kevin was trying to convey in this post. However, there was one picture on the same post which caught my eyes and to which I could relate completely.

(src = http://www.codecraft.info/images/processSeesaw.jpg)

The picture nicely describes how the two processes are loaded with respect to the Product Design and actual Product Development. Whether it is intended or not, there is typically a lot of upfront design effort in Waterfall. Whereas the Design process is more emergent in Agile. As they say, more important in Agile is the working code.

Although we have been playing around with it for more than year and half now, over the last few quarters my company (GlobalLogic) has invested heavily in and adapted the new generation development platforms like Ruby-on-Rails (RoR), Adobe AIR, etc. One might term it to be slightly slow in comparision with the industry adaption trend. However, our adaption was also driven by the needs of our clients. In the recent few quarters, we have suddenly observed that these platforms have now become main-stream. RoR/PHP is becoming a popular option in building the modern web apps whereas AIR seems to be the current ‘cool kid’ on the desktop side.

Adapting a development platform at the early stages of its evolution is always a challenging decision which an Engineering Head has to take for the product. I have always believed that adaption of any new technology is driven a lot by the herd mentality. Just because of the notion that many others are also using the platform, many a times the selection of a development platform becomes a blind decision. On the flip side, if a choice is about selecting a new platform - the same ‘herd’ mentality also comes in. The onus is more on the Head to prove his/her choice criteria rather than simply using the regular proven and established ones. Also, it is one thing to build up an experimental system using the new platform. However, the decision to adapt the same platform for engineering commercial products can be a hair-pulling one. Many a times in the end one has to finally depend on the two G’s - guts and gamble. Also the decision-maker will have to be continuously ready to answer questions associated with the hypothesis as and when any bad news associated with the platform (e.g. Twitter’s challenges attributed to RoR) or the product (e.g. initial breakdowns of the product) trickles in.

Because of the nature of the products we have been developing in my group, we felt that RoR was a very good platform choice for the same. So far (and I am knocking the wood here) our choice of the platform seems to have been validated based on the results we are seeing. It is amazing that how much dramatic productivity-related improvements these new platforms have made over the years as compared to some of the older generation-ones. I have myself observed this in my teams. Probably one of the big reason for this improvement is that these new platforms have started becoming very specific (e.g. web in the case of RoR) rather than the general purpose language platforms like C/C++, Java, etc. Dion Hinchcliffe in his posting “Creating Open Web APIs: Exploring REST and WOA in Rails 2.0” refers to productivity improvement numbers in the range of 10 to 20 times. Considering that programming time (or the development time) is the biggest cost of product development, the savings because of these improvements can be enormous. The built-in practices associated with Unit Testing, Agile, Reusability, etc. also seems to have aided in the aspects of building a more quality product.

Lately, the news about Twitter performance/uptime related challenges seem to have raised a lot of speculation on the run-time performance capabilities of RoR. While nothing has been proven as yet, such questions associated with newer platforms is enough to keep one awake in the night. Before jumping into RoR, I had in my mind that the run-time capabilities of these new frameworks would be weak in comparision with the compiled software platforms like Java, C++, etc. The above post by Dion has a good explanation about the same -

One is that the more popular, older programming languages tend to be relatively low level and general purpose and were designed for a different, older set of constraints. This has given us baggage that is often not very applicable to the modern Web-based world. Second, we’ve become very good at understanding the idioms and “syntactic sugar” that makes developers more productive for Web development and we’ve put that into the latest generation of programming languages and Web frameworks. Unfortunately, the combined newness of these new Web development platforms and their preference for coding time efficiency in favor of run-time efficiency has conspired to make the results they produce relatively slow and resource inefficient compared to what is potentially possible. Newness in this case is also a kind of performance tax since we just haven’t had enough time learning how to make these new platforms perform well at run-time, similar to early versions of Java before the advent of the Just-In-Time (JIT) compiler.

Based on the above and my experience until this stage - I am more comfortable in recommending these modern languages towards Consumer/B2B products as compared to telephony/banking transactional products. For the preferred products, many a times it seems like the advantages associated with improved developer productivity far over-weighs the slight runtime performance disadvantage these modern languages bring in.

Also my opinion is that it is too early to start comparing the modern development platforms with the older programming environments. Increased usage will drive the initiatives associated with the strategies targeted towards improving their weaknesses.

Thoughts, comments, and suggestions are welcome.

[This is fourth in my series of blogs about Product Engineering Approach for Startups. In my previous blog, I had talked about why it is necessary to implement a Goals-Driven Planning Approach.]

My group - Version 1.0 in GlobalLogic reached a very important milestone this week. Using an unique business and engagement approach, we successfully rolled out a Version 1.0 of one of our first client in the group. This was done in-time and within-budget with all the quality requirements which we had agreed with our client. Two more products are in its way to be completed within the same parameters in the next few months.

I would not like to claim that we were the first to finish a project on-time or within a fixed budget. However the unique thing about this achievement was the approach and methodology we took to reach to this stage - especially when we had to consider the driving forces behind rolling out first version of a product. (fixed time to go-to-market, changing or evolving requirements, and most important a fixed budget)

We are currently engaging with more than 8-10 organizations who are keen in seeking our help in soup-to-nuts aspects of engineering and rolling out their product to its Beta. While each of these organizations bring in an unique vision and passion associated with their products, there was one thing which was common in almost all of them. Almost all of them - in our first meeting with them - were keen in knowing a ball-park number associated with how much time it was going to take to build their product and how much was that going to cost them. We had to tell most of them that in software world there was probably no formula or a calculator which existed which could easily tell them that. Well, unfortunately, at least we did not have one!

Having said the above, we also do realize it was also important for such product entrepreneurs to get a feel of the time/cost numbers before they jumped into their mission. So to all of them we typically have been suggesting the following thumb-rules.

• Regarding time required to build a Version 1.0 = This, IMO, for a product at an inception stage should be same as when the product should be taken to the market. So time estimates to build the product should be the same as the product’s pre-determined go-to-market date/s.
• Assume that it would always take x amount of time for one person to build up a product feature. Increasing the number of people does not reduce the time. So for example in 98% of the scenarios, it is not possible to reduce the time to build a feature to half if you have twice the number of people working on it. This is a very important aspect to be considered in software engineering.
• It is a risky proposition to build the first version of the product on a fixed cost; it should be always built on a fixed budget. So the best possible answer associated with how would it cost to build a Version 1.0 of the product is typically best answered by the entrepreneur themselves.
• You can assume fixed regular cost associated with the raw materials required to build a software (intellectual property, human services cost, hardwares, softwares, etc.)
• Only variable which remains is the product scope which the product entrepreneur wants to be part of the Version 1.0 release. This is an important variable which the product entrepreneur can use to optimize time and cost associated with Version 1.0

Hope the above thumb rules helps in some manner with the estimations. As Sachin puts it very nicely - “There are two things any product entrepreneur has in abundance - vision and passion. There are two things which he/she does not have in abundance - time and money.” Keep that in mind while doing your estimations.

Thoughts and comments are most welcome.

Slate is carrying a very interesting photo essay on one Herman Perry - who was an African American World War II Soldier and became a fugitive after shooting down one of his white commanding officer. This essay titled as “The Greatest Manhunt of World War II” is based on a book - “Now the Hell will Start” written by Brendan I. Koerner. Herman Perry was positioned in Burma to build a road connecting from Assam in India to borders of China through Burma. After he shot one of his officer, he escaped into the jungles of Assam and took shelter with the Naga tribes. He infact became one of them and lived with them for many years (married the daughter of the head of the tribe) until he was caught.

The essay describes how much active US forces were on the Indian soil during the World War II. How many lives just get lost just to follow some fancies of the superiors. It is also so amazing that such unique historical stories can get so easily lost.

Image via WikipediaAlthough I have never seen them in the wild and I have never touched the African continent as yet, I have always been fascinated by the African Wild Dogs (biological name: Lycaon pictus) (wikipedia link) whenever I have heard or read about them. Although they may not give the most soothing view to the eyes, may not be majestic, and have plenty of ill-founded myths going against them, there are many amazing things about them. IMO, some of them can be translated into some real practices in our real life especially in Software Project Management. But more about that in some future posts.

Follow the link to the wikipedia to read more about these African dogs. Quite different from many of their other cousins - these dogs live in packs in wilderness, are hunters by nature, and come very close to modern dogs. All types of wolves also fall in this category. Also, with whatever I have read about Australian Dingos, they also come close to the African dogs. However there are certain characteristics that are still unique to the African Dogs.

Some of the things which are certainly fascinating about these African dogs -

• Ability of each of the dog to live and survive in a pack while maintaining a unique role for themselves.
• Understanding the roles and strengths/limitations of others in the pack. These animals play to other’s strengths and complement wherever required for other’s weaknesses. For example, their ability to regurgitate to feed other pack members such as the sick, injured or very old is certainly unique.
• They do not seem to be instinctive hunters as many other wild animals. They have evolved their hunting tactics with learnings over the years.
• They have the highest success rate in their hunt missions probably because of the attribute mentioned in the above bullet point. More than 75-80% of their hunts translate into successful kills. Compare that with the big cats like lions whose success rate is less than 50%.
• Cursorial hunting ability - ability to run long distance to get their hunt.
• Recursive divide and capture style of hunting - ability to continuously break and capture their target hunt to maximize their success rate in their hunt.

Take some time to read more about this beautiful animal by googling around on the internet. It is sad that this intelligent specie is on an endangered list now. By the latest what I have read, less than 5000 of them are remaining. With a mortality rate of more than 50% and life expectancy of around 10 years only, that surviving count is not that much.

Consciously or sub-consciously - I personally think that I have always been extremely liberal in the use of metaphors (or similes or personifications) in my day-to-day communication. I have always felt that most of the times it has always helped me in communicating my thoughts across.

This weekend I came across this blog by Dave Pollard which I thought summarizes the advantages and risks associated with using metaphors in regular communication quite well. According to Dave, the advantages of using Metaphors as a technique/device in communication has its plus -

“Use of these devices is a very human tendency: They make things easier to understand. When used properly they can bring clarity the way no amount of detailed explanation or information can, and do so very quickly. They can also trigger the imagination, and produce brilliant creative insight. “

However, according to Dave overuse of such techniques in communication can lead to over-simplification of the point which needs to be communicated. Interestingly, Dave also feels that this is a representation of the kind of society we are staying in today - where there is an increasing demand on simplifying things because of the over-whelming feeling that information seekers do not have enough time.

The blog is an interesting read and I would encourage all of you to read the same. While I think I will continue with my use of metaphors in my conversation, however I will certainly keep Dave’s parting advice in mind -

The only practical answer is to learn (and to teach young people) to recognize them, and to recognize them for what they are: Useful, incomplete, imprecise shorthand representations of reality.

Thanks for the great advice, Dave!!

Before anyone gets offended by this, let me say I am not saying this.

Boston Globe carries an interesting photo essay on author Mark Bauerlein’s new book “The Dumbest Generation: How the Digital Age Stupefies Young Americans and Jeopardizes Our Future“. It looks like Mark’s definition of current generation is the current age-group of thirty years and less. Pooof, that leaves me out!

Needless to say, Mark was keen in trying to create some flutters (possibly for his self-interest) and looks like it certainly evoked that (refer to the message board associated with the article).

So what is my opinion? I certainly don’t see the current generation the way Mark is seeing. Ofcourse, I do have a big wish list that the current generation should be doing certain things different and better, however I personally have a very positive opinion of this generation compared to the times when I was possibly in their category. The current generation’s spelling skills may have taken a beating, however they are now communicating to more number of people than what I did in my time. Mark assumes that they are reading less books. That may or may not be true. Even if it is true, this generation is now interacting with so many other channels of information broadcast (Web, TV, Podcasts, etc.). Probably I can point to many other similar points. But then I may be given too much value to Mark’s viewpoints.

Read the essay for the fun of it. If any of you belonging to the so-called ‘dumbest generation’ pointed by Mark feel offended - I would just say to chill out and relax. You guys are doing good!

Let me first describe what I mean by ‘repeat‘ user. I think there might be a better term to describe this kind of a user, but the term is escaping me right now. By repeat user I mean the user of the product who has already used or checked out the product once and now is returning back to use it one more time. Hope you are able to relate to the category of product user I am referring to here. Almost all of us have been in this category one time or the other.

For the sake of this post, let me refer to the repeat user as Mr. X.

In my opinion and experience (both from the experience of engineering a product and also from being an end-user of the product), the perspectives of X towards his needs for the product are quite different as compared to what it could have been when he would have seen/used the same product for the first time. It is also well known and well understood that the success of a product - both from usage and commercial angle - is measured more from the repeat user perspective (and not from the first-time user perspective). I am not saying that the first-time user’s needs are not important. The requirements of first-time user needs to be understood well also because they are the ones who would translate into repeat users if things go well.

So what is so different from a product design perspective between the ‘first-time user’ and ‘repeat user’? First-time users are more keen on exploration. Repeat users are more keen on focusing on the regular functionality. A sophisticated design can certainly impress the first time user, however simplicity and ease is the key for a repeat user. As a repeat user for many products, if I were to quantify my usage, more than 75% of my interaction with the product is of a repeat type. Something which I have already done once and I am just repeating the same tasks again. My requirements from the product are now as to how it enhances my activity needs based on my usual usage patterns.

In my experience, I have noticed many product designers failing to think about the product from Mr. X’s perspective. Best products are those which keeps in mind the needs of this user. It is my strong opinion that in the end it is users like Mr. X who finally decide the fate of the product.

Silicon India has carried a cover story on Version 1.0 titled ‘GlobalLogic: Incubating Ideas, accelerating innovation“.

Provides a good overview of what Version 1.0 in GlobalLogic is all about.