“Miscommunication” Scenarios in Daily life
I want to start with some stories to illustrate miscommunication examples that happen in the real life. I am sorry that I have to mess up Bob and Jill’s life again. They are my favorite use case actor and actress since when I was in Pittsburgh.
Scenario 1: Bob is preparing a Xmas party. He is trying to call his old friend Jill’s cell phone +1(425)555-5555. However, Jill changed her cell phone a month ago. Then Bob tries Jill’s office number +1(425)666-6666. Since it is Friday 6PM, no one picks up the phone. Then Bob dials Jill’s home phone +1(425)777-7777, still no luck. So he just left a voice mail.
Scenario 2: Thanks to the new technology and the Internet! Bob is using Windows Live Events to create a party invitation to all his friends. He found Jill’s Gmail account jill@gmail.com and sent her the invitation as well. When Jill returned the call on Monday, Bob realized Jill is only checking Gmail account once a month. As Jill suggested, Bob sends invitation again to Jill’s Hotmail account: jill@hotmail.com
Scenario 3: The party went well. Bob took quite some photos of Jill and shared them on Windows Live SkyDrive with Jill by granting access permission to jill@hotmail.com. Jill just got a new Windows Live account jill@live.com and starts using it every day. However, she has to log back to jill@hotmail.com to view those photos.
Scenario 4: Jill is very upset after seeing the photos, as they are not as pretty as she had thought. She decided to block Bob’s from Windows Live Messenger for a while. Unfortunately, Bob found Jill was trying to block him because Jill has two Messenger accounts for Bob bob@msn.com and bob@hotmail.com, and she forgot to block both.
Have you seen some glitch here? What’s the root cause?
Identity-based Communication is Problematic
Before we continue, I want to clarify the definition of identity. I do not want to start a philosophical discussion. Rather I want to put it in a practical way, as long as you know what I am trying to say. It is good.
Identity is anything that we can use to distinctively identify an offline person. Identify can be: phones, emails, IM addresses, physical addresses. It can even be devices exclusively owned by the person. As long as we can uniquely identify the device, we can consider the device is an extension of the person.
The miscommunications scenarios given above are Identity-based communication pattern. It is problematic for two fundamental reasons:
1. Identities change frequently. People change phone number, email address and move to different cities. Communication channel will be broken as identity changes.
2. Identities are swarming. You can easily enumerate 10+ identities that people can reach you. The more identities you have, and the more complicated the communication pattern will be.
Identity-based communication is legacy from old days for ages. Unfortunately, the legacy constraint is too strong for us to break through. Even for new technologies, we still build the systems in the identity-based way, which is exactly what Bob and Jill have experienced.
Fortunately, we realize the problem and making progresses to change the situation.
A Better Solution by Linking Identities
There are many good examples of improving identity-based solution by linking identities. Our life is getting better, even though sometime we do not realize what kind of problems those solutions are trying to resolve.
Example 1: Google Grand Central provides a unified phone number solution. For example, in scenario 1, Bob just dial one number, all Jill’s phones will ring until one of them is picked up. Therefore, Bob just need to remember one phone number, rather than three phone numbers to reach Jill. It is an example of linking phone identities.
Example 2: Windows Live Linked ID provides a solution to easily switch between Windows Live IDs. Therefore, in scenario 2, Jill can switch from jill@live.com to jill@hotmail.com without login back and forth. It is an example of linking email identities.
Example 3: Windows Live Messenger provides a solution to unify Email and IM Address. People might be confused: “hey, what are you talking about?” Yep, one simple fact that people do not realize is that: “Email is email, and IM is IM”. Email and IM are totally different communication channels. They happen to have the same address does not mean they are the same thing. For example, in China, QQ is IM, but it is not email. Another example, IM with @passport.com domain looks like email but there is no mail box associated with that domain. (Emails sent to @passport.com will be rejected.) The fact that many IM systems using email as IM address is a great example of linking between IM identity and Email identity.
Example 4: Many web sites provide functionality of “register my computer”. So, next time user does not have to manually login again. It is an example of linking the user’s device identity with the user’s account identity. You can also consider finger print reader as a similar example as well.
Example 5: There is another great example of linking email identity and phone identity. However, I do not think I can talk about it now.
Linking identities makes our life better. However it is still not the ultimate solution as it did not resolve those two fundamental problems of identity-based communication: identities are frequently changed and swarming.
Contact-based Communication – One Level Abstraction and the Ultimate Solution
Let’s think over about the first thing of software engineering – requirement elicitation. And let’s go back to scenarios between Bob and Jill, and figure out what are the real requirements.
Scenario 1: Bob is trying to reach Jill via phone. Bob does NOT care +1(425)555-5555 or +1(425)666-6666.
Scenario 2: Bob is sending Jill invitation via email. Bob does NOT care jill@gmail.com or jill@hotmail.com.
Scenario 3: Bob is sharing photo with Jill. Bob does NOT care jill@hotmail.com or jill@live.com.
Scenario 4: Jill is blocking Bob’s IM address. Jill does NOT care bob@hotmail.com or bob@msn.com.
We realize one thing: people are only caring about the real person, rather than his/her identities. When bringing the business online, what we really need is the one-to-one online abstraction of the offline person, rather than the person’s online identities. For the one-to-one online abstraction thing, we reuse and redefine the concept of contact.
Contact is the one-to-one online abstraction of the offline person. It is the collection of the person’s online identities.
After clarifying the definition of identities and contacts, the ultimate communication solution can be described in three phases. Please note: we consider any interactions between two people (requester and recipient) are within communication problem domain, which include email, phone, IM, mailing, and even permission granting and revoking etc.
1. Communication endpoints (requesters and recipients) should be contacts rather than identities.
2. Requester decides communication channel.
3. Recipient decides the binding of his/her identities and communication channels.
For example, Bob decides sending invitation to Jill’s personal email. Jill decides which email address (jill@gmail.com or jill@hotmail.com) is used as her personal email.
Conclusion
When the offline people come online, they are shielding behind their identities. Over years, software systems are designed based on people’s online identities. Due to the fundamental weakness of identity, those systems are running into problem when trying to resolve communication problems. Ultimately, we need to shift the design principle from identity-based to contact-based solution, which is one level up abstraction and one-to-one mapping of the real person offline.
Two weeks ago, ProClub (a.k.a Microsoft gym) introduced a new lock system in the locker room, which requires inserting your member card before locking the cabinet. I left my member card inside the lock the first time I use it. I am a discipline person, left or forgot something rarely happen to me. I only left my work badge once, even that time I was still carrying the empty badge holder.
I blamed myself for being careless. The next day, I went to ProClub to get my card back. The front desk lady was so nice to me. She went to an A4 printer paper box fully stacked with member cards. She grabbed hand full cards with last name start with “G”. I felt less guilty since my last name is only 2 characters, which could be easier for her to help me find my card back. It is all because of my carelessness. I asked her how many member cards in that box? “Few hundred” she answered peacefully and said “thanks for your patient”. I roughly estimated: an A4 box can hold nearly 4 ~ 5 hundred cards; From another angle, a hand full of cards can be 50 to 70, which all have last name start with “G”! Assuming five thousand people visit ProClub every day, nearly 10% people left their cards in the lock for the single day, and it was already the second week after the new lock system was in place. If 10% people make the same mistake, it could no longer be called “user error”. I felt relieved and I know whom I should blame – the lock designer.
What’s the requirement? What is the problem the designer was trying to resolve? I asked the front desk lady, the old locks system work perfect for me and why we change them. The answer is to prevent single person from using multiple lockers. (I do not want to argue if it is a valid requirement. We assume it is valid.)
What’s the design problem? I’d say the lock does not provide a way to remind the user of leaving member card inside the lock. Or put in another way, the design does not provide necessary indication of the existence of member card in the lock.
How to solve the problem? Simply put, provide necessary feedback. There are two solutions in my mind. #1: make the front panel keep on flashing light as long as there is a card inside the lock. #2: after user unlocks the cabinet, the lock should keep on beeping until the owner removes the card from the lock.
How to prevent this happen to me? I will program my life to prevent this happen to me again. Did I just say “program my life”? Yep, I am damn good software engineer. I will wrap my sock around the visible part of my card after inserting it to the lock. When I dress, it will remind me of removing my member card from the stupid lock.
How many times we realize that the software was implemented in the way very different from the original design? It is an overused example to describe the problem we are facing every day. That’s the reason I will not call design doc review until I have implemented certain amount of the prototyping code and have the confidence about the design accuracy. Software engineers hate to write design document, and it will change during implementation anyway. And sometimes, the design docs are more about recapping what we have done rather than the implementation guideline. I do not think it is because the software engineers are incapable to design accurately, but why?
Let’s give a real life example, say you are planning the trip to the following address:
One Microsoft Way
Redmond, WA 98052
U.S.A.
I am pretty sure you will do a good and accurate trip plan by using tools like http://local.live.com. But, what if I give you the following address (my home address in China)?
Bi Tao Bei Yuan
Zhong Shan District,
Dalian, Liaoning 116001
P.R.China
Even you might have excellent route plan, you will not very confident about issues like, foreign language, travel insurance, car rental, hotel, food, medical emergency etc. It is exactly the same problem we are facing in software design - many issues beside original requirements are vital and hidden. Most of projects we are working on today are like trips to foreign countries, which we have never been to. There are uncertainties along the way and some unknown issues will not pop up until you actually get there, which could impact your design dramatically. How to deal with those hidden issues and make your design more accurate? There are couples of lessons I have learned over years and want to share them with you. You are welcomed to add more.
First of all, identify the scope. Believe or not, many projects do not have a clear scope until they are called code completed. Put in another way, the scope of software are sort of determined by development timeline. It is not anybody’s fault. It is merely one of the characteristics of software development – unpredictability. I am not saying that we should precisely define the scope before design, which is not practical at all. However, I strongly believe we should have clearly defined and prioritized items in a pipeline, which might or might not go into scope. By having the big picture in mind, we can avoid changing software design dramatically whenever we adjust the project scope.
Secondly, identify the problematic items within the scope. Those items are unfamiliar to us and will cause uncertainties. We do not want to get into a situation that, when the project is 80% complete and find out that a critical component is technically not feasible. Here is an example of uncertainty from non-functional requirements. Say, we design online gaming software over some platform, later we realized that the platform cannot provide the real-time message delivery channel required by your gaming system. What a “surprise” if we have completed most of our code on top of that platform?
Third, mitigate the uncertainties (also the risks) by prototypes. This is the skill I learned back in CMU. Uncertainties or hidden issues in software development can cause dramatic architecture impact or fail your project right away. To ensure we are heading the right direction with correct assumption, we need to do some experiments. They can be very small and even throw-away projects, however they should cover the real concerns we have in mind.
Software design it is very complicated tasks. There are tons of books talking about it. They start from different perspectives, all come to one common goal – make software development more predictable.
