The Story of Writing

Andrew Robinson; Thames & Hudson 1999

WorldCat•LibraryThing•Google Books•BookFinder

First impression

When you take this book in hand you notice the weight immediately. It is made in very thick high quality paper due to the numerous photos and illustrations. When you scan it, the impression is excellent and you want to stop at every page to have a better look.

In details

The whole book is organised around sections of 2 pages: left and right. So, in a way, wherever you open the book, you are in front of an end to end story. This construction is clever as it gives to the reader a nicely manageable pace for the reading. Each topic is generously illustrated with photos, diagrams, tables and all things necessary to make the point. The range of topics covered is simply amazing. I’ll give you a few: origins of writing; sign language; pictography; cuneiform; Mayan alphabet; undeciphered scripts; runes; Cherokee alphabet; Chinese; Japanese; etc. All in all you cannot get bored with this book. It is fascinating and entertaining. I had a real great time with it. On the top of that, I can say that I have a daily use of some knowledge acquired with it. It helped me understand part of the limitation of the written language and the diversity of answers given by humans to this basic problem of distance communication. It is one of those books that keep a particular place in your library.

Conclusion

I warmly recommend The Story of Writing. Anyone interested more or less in what allows us, humans, to communicate without the incredibly strong constraint of physical contact should read this book. Not only you will find answers to most questions you may have, but you will also appreciate the logical construction and the build quality of the item.

Score:

Let’s Think About IT

Read online: http://issuu.com/develop/docs/dev116_web.

PDF Download: http://www.develop-online.net/digital-edition. Look for the issue #116 in May 2011 page 47.

The version in the Develop Magazine is obviously nicer to read with diagrams. The magazine is definitely worth reading as a whole!

————————————————————————-

“Dealing with a Serial Killer”

We all know that “requirements” quality is a major factor in developing a hit title. The subject has been covered at conferences for years and books have been written on how to model and improve them. But to my mind, the deeper and root cause of many trans-project bottlenecks is often intrinsic and completely missed – namely the subject of “ambiguity”.

The first challenge faced by games designers is to accurately convert your “world of ideas” into a “world of words”, i.e. into a games design document (GDD). This exercise is essential for scope, but will also create issues for the following reasons: (1) Some ideas are not conscious enough to be converted into words so about 30% are lost; (2) A further 20% of the ideas that can be converted are partly “damaged” on the way; and (3) When the written document is received by others for implementation, ambiguities remain that require interpretation and some of these interpretations will be wrong, resulting in 20% being badly implemented.

To formularise: For every 100 ideas or features desired only 44.8% (100×0.70×0.80×0.80) are implemented accurately in the natural world of software. Yes, less than half and a major cause of change requests.

Why? Because written language is treacherous! It was originally invented to calculate how many cows or slaves we bought and sold at market. More typical communication is conducted face-to-face and major studies show that 80% of a message is not conveyed by words, but rather by human interaction such as touch, body language, facial expression, inflections of speech, etc. Beyond that, even hoping for precision in a written document is pure fantasy. The best example is that after 1,000s of years of writing laws, we are still totally unable to write an important one that is clear enough to not demand a first “interpretation” by a solicitor or judge. That’s how lawyers make their living.

I have seen some astonishing statements in GDDs I have worked on. For example:

• “…the amount of time this takes depends on the weapon and the length of time the player has been firing for.”
• “If the target is far away, the crosshair remains…”
• “Accidents need to be spectacular. (Without being gruesome!)”

None of these descriptions are testable. They appear to be sufficient, but will lead to interpretive troubles later. And that’s when your change requests will begin. They contain no clarity.

For example, if I told you that, “I’ve had a tough day.” you would simply nod in affirmation. But then if I ask you what I meant, you may begin to see problem. My day may not seem so tough to the receiver of the message – it’s based on their experience. This phenomenon is common in GDD’s and, all too often, around a dozen ambiguities are common per page. All are excellent dream makers but publishers put fortunes on such statements. I call that a big gamble. In fact, the biggest culprit is not the hard-working human behind his/her keyboard but the written and natural language; excellent for writing a novel or poetry, but so weak at precision. Would a mathematician ever express a differential equation in plain English?

So, what can we do to improve things? Below is a process we often use with clients (in my writing and therefore partly flawedJ), but the act of conducting the exercise eradicates the vast majority of ambiguities affecting your internal team or publisher.

1. Scan the GDD and any other requirement documents to look actively for ambiguities
2. Have a number of your core team carry out the same exercise
3. Write down each one ambiguity
4. For each one found go through the following cycle:
   1. Identify the type of ambiguity (you need to define a typology of the ambiguities you encounter for your kind of project – it is likely to be different for an FPS, a RTS or a simulation game);
   2. Grade the severity, i.e. the consequences it may have if misinterpreted;
   3. Identify a possible mitigation solution;
   4. Assign the removal of the ambiguity to someone;
   5. Measure your level of confidence in the possible solution;
   6. Measure the level of testability once cleared;
   7. Measure the overall risk value of the ambiguity on the project.

For the ambiguities you cannot clarify (there will be some, but less than you think), flag them and make sure that both studio and publisher agree that the ambiguity (and its possible consequences) are acceptable and better left as is, rather than resolved.
It is important to understand that removing an ambiguity is not necessarily done by adding words to the document. Often, the more you write the more ambiguities you are likely to add. It’s the very nature of the trap.

This strategy will present you with a completely different understanding of the risk on your project. You make the project testable. You drastically increase the quality of the expectation of the different parties before each delivery. The level of trust amongst the project’s stakeholders is built tenfold. Ultimately, your project will gain a greater ability to complete on time, within budget and to all parties’ expectations.

Read online: http://issuu.com/develop/docs/dev114_web.

PDF Download: http://www.develop-online.net/digital-edition. Look for the issue #114 in March 2011.

The version in the Develop Magazine is obviously nicer to read with diagrams. The magazine is definitely worth reading as a whole!

————————————————————————-

“You cannot work with these guys!…”

We all know that games development has gone global. This globalism is in line with the trend of developing offshore, in less expensive or more competent countries, creating in fine a multicultural project. In places like London, you’ll find people from all over the world in the same workplace. At first, this multicultural approach may seem to present real cost efficiencies, but what is the real price we pay? Team human dynamics are a complex issue and looking at the outsourcing savings alone can prove to be a false economy. Unfortunately, this little gremlin will only show himself late in the project, costing ridiculously high amounts of money.

We all know that if you are British and work with a Japanese, an Indian or even a Frenchman, the nature of the relationship might be more or less fluid and smooth. As Richard Lewis, one of Britain’s foremost linguists and author of “When Cultures Collide” summarises it: “A working knowledge of the basic traits of other cultures (as well as our own) will minimize unpleasant surprises (culture shock), give us insights in advance, and enable us to interact successfully with nationalities with whom we previously had difficulty.”

What does it mean to be British, American, French, German, etc.?

Cultures have been studied by anthropologists for a while, but the analysis of what a culture is made of is rather recent. Several definitions have been provided and we will retain the definition given by Geert Hofstede, a Dutch social psychologist who did a pioneering study of cultures across modern nations: Culture is the unwritten book with rules of the social game that is passed on to newcomers by its members, nesting itself in their minds. In other words, it is the sum of all the rules you have learned when you were a child without necessarily knowing you were learning them. It is important to note that no culture is better than another, they are just different.

Cultures dimensions

Most authors who have worked on this question have identified several “dimensions”. The general idea about cultural dimensions is that human beings have been confronted by the same problems all around the world. What makes them different is the answers they have assigned to these challenges. Understanding these, and the answers given, is the key to a better relationship. Let’s illustrate this point with some examples.

For instance, one of the earliest authors working on the structure of culture is Edward T. Hall, an American anthropologist best known for his work in intercultural relations and communication. Among other dimensions, Hall identifies the concept of rich or poor context in the language we use. A rich context would correspond roughly to a lot of assumptions made when we communicate. A poor context would reiterate what is “already known” in order to remain clear and unambiguous. For instance, Latin countries like France or Spain are using more of a rich context in communication while Germans will use a poor context. Make them work together and it is likely that they will despise each other’s way of writing a report or running a meeting. The rich context worker will produce shorter reports due to assumptions made compared to the poor context worker who will play safe by reiterating the “already known”. Hall also identifies the concept of culture monochronic and polychronic. To simplify, a monochronic culture tends to do one thing at a time when a polychronic culture tends to do more than one. Put a polychromic worker in collaboration with a monochromic and it won’t be long before they declare that it is impossible to work together. The polychronic worker will declare the monochromic worker as a mono-maniac where the monochronic worker will believe his polychronic colleague is unstable and unfocused. Have you ever felt that you couldn’t understand the work pattern of a colleague? Has it brought you to the conclusion that, “you just can’t work with these xxxx (replace xxxx with the country you can’t understand.)? Well, here you are, it might well be the first key to your problem.

To illustrate my point further I’ll introduce another dimension presented by Hofstede et al.: Power Distance Index (PDI). It is the degree of inequality between people that is assumed to be natural in the society.

Basically, whoever has worked in France and England knows how much easier it is to get in touch with a high level decision maker in UK than in France. This is because British people have a very low (one of the lowest actually) Power Distance Index level, while the French have one that is well above average. This difference can create very strong frustration points and ultimately teamwork troubles. What is true between Great Britain and France would be even worse between Britain and China as China’s PDI level is one of the highest. How is it with Germany or Russia, or any country your company is working with? It is better that you know than to put you whole project at risk. – Your entire collaboration quality is at stake!

The implications are huge on business and cannot be ignored. The resulting costs of such mistakes are avoidable.

Conclusion

The Games Industry is by nature a very international one and without due consideration the cultural backgrounds of staff can be a project killer. Unfortunately, judging colleagues (as odd, weird, unacceptable, uncivilised, etc.) is what we do instinctively. Unfortunately, being judged is also what we personally dislike most. It can create very strong negative reactions that most of the time will never be shared in the open. This can be killing your projects slowly, including the ones with the best people.

Building a fruitful relationship with someone comes in two stages: (1) study and know your own culture in the first place and then (2) investigate what makes your team mate different. Always keep in mind that the global issue will be about “normality”, not about what is right or wrong (that’s judging again). This normality will be very different depending on what you have been taught was “normal” as a child and experienced in your community.

Seminars, workshops and special team building events are key elements to the success of your international projects.

Finally, be aware that these Cultures specifics actually have the potential to kill your project twice – once during the development of the game, and once again when it goes on sale. We all know that a proportion of games do not work worldwide. It is likely that cultures have something to do with it. Do we believe that Raph Koster’s definition of “fun” once applied will have one and only one version in the world? Or more simply, is “gruesome” perceived the same way everywhere?

Studying cultures can help you to create better games, with a wider global appeal, whilst improving your development team’s efficiency.

In short, and I’ll come back to that, living in harmony with a different culture than yours is difficult and there are so many good reasons for that that you should not feel bad about it. At the same time, we have seen in the recent years enthusiasm for off-shore outsourcing. Depending on what country you are based in, the elected off-shore country is always one which is more or less speaking your language. I’ll take two examples: United Kingdom will outsource in India due to their English heritage. France will outsource in North Africa for the same reason. Of course, other parts of the world are heavily used, like Russia, Eastern Europe, China, etc. But anyway, for at least UK and France, I can say that common language is seen as the way to work together.

Now what happens? Every day, we hear more and more about disappointed companies regarding the success of their off-shore outsourcing. And most of the time, the complains are the same and turn about inability to understand each other, deliveries that have not much to do with expectations and in the end, some managers recognise they would be far happier if they could stop dealing with “this lot over there”. In a word: misunderstanding!

The point is: communication is not about using common words and common grammar. Culture is not about TV programmes or football results (another topic for a next article regarding off-shore and call-centres). Until we acknowledge the real complexity of culture, the real meaning of belonging to a people, the serious complexity of human communication we will end-up in misunderstanding. This misunderstanding can be very costly indeed when a company is injecting huge amount of money off-shore with the expectation to get things faster and better.

In “Beyond Culture”, Edward T. Hall, explains that whatever the domain, there is something universal in communication: the message received by a target is always composed of the message, history (previous communications), internal context (pre-programmed reactions from the receiver) and the external context. If the external and internal contexts are supposed to play an important part in the decoding of the information, we are in a “rich context”. If the message contains all the information needed for the decoding, then we say the context is “poor”. Of course we permanently adapt to the situation but there is one element we hardly adapt to: the culture and all the things that we are all supposed to know. The problem is that during a cross-cultural communication both sides of the channel will make the wrong assumptions by considering a common ground for this context. This is precisely how we end-up with reactions such as:

• “How could they convert what we said into this?”
• “It was quite obvious that we would not want that!”
• “We have to tell them everything like children!”
• And so on…

In fact, yes, when we are dealing with a different culture, just like children, we have to learn again the basics. So, I hear you say, what do we do?

First of all, we need to recognise that fact that whoever we are dealing with, as soon as they are from a different culture (and you do not have to go far from home to find that) there will be misunderstanding. It is the nature of the relationship we are creating in the first place. It will then become far easier to fail than be successful. Then we need to understand that being ISO or CMMI compliant will not solve that, it will just guarantee that the misunderstanding is following the agreed process! You will get high quality rubbish! Then we need to take action to tackle what the real problem is: a cross-cultural communication challenge.

I will not detail here all the steps you need to take to improve the communication in the context of an off-shore project bur I can mention a few:

• Produce less plain English documentation;
• Increase the use of modelling languages such as UML which convey the poorest context you can think of and therefore maximises your chances to share the same identical understanding;
• Agree on the framework/process you will use and incorporate in this process steps that will identify risks, potential misunderstandings and errors as soon as possible;
• Use a risk driven approach to your development;
• Use an iterative development cycle with short iterations (I mean short!);
• Increase the human to human relationship and do not trust that what you have sent in writing will happen fine. Follow-up, talk, meet and remain calm on both sides as everybody is probably trying his best;
• Run workshops on cross-cultural communication so that everyone understands the nature of the problem to come;
• Stop thinking you are going to change the other side. That will not happen!

In the end, in these times of globalisation, I believe it is futile to try to avoid these problems. Off-shore or not off-shore, companies are international and very often the off-shoring is in fact using another part of the same company. Belonging to the same company is a plus but not a guarantee to be understood. I strongly believe as I have experienced it myself, that working on the matter with the firm intention to remain intellectually honest and true is going to make a difference and drastically increase the likelihood of success in your projects!

Let’s think about IT!

I have delivered again and again courses about requirements management and requirements gathering. There is no surprise to that, as bad requirements are the main reason for failing projects. The ways to get “bad requirements” are countless. I am not going to detail them today. Today, I am interested in an interesting phenomenon about natural language. It happens that I had to work with the topic of natural language during my PhD and since then I keep an eye on it. As I am also interested in learning languages (I have learnt Hungarian out of curiosity and intellectual challenge) I keep a second eye on it. So, what do my eyes tell me?

I bought the other day “The Story of Writing” by Andrew Robinson at the British Museum (I love the British Museum and its library is killing my wallet every time I go). In the introduction it talks about the different writings over the world. We all know that learning Chinese is far more difficult than learning English. Of course, it is obvious but the explanation why is still interesting. I quote:

All scripts that are full writing – that is, a ‘system of graphic symbols that can be used to convey any and all thought’ (to quote John DeFrancis, a distinguished American student of Chinese) – operate on one basic principle, contrary to what most people think, some scholar included. Both alphabets and the Chinese and Japanese scripts use symbols to represent sounds (i.e. phonetic signs); and all writing systems use a mixture of phonetic and semantic signs. What differs – apart from the outward forms of the symbols, of course – is the proportion of phonetic to semantic signs. The higher the proportion the easier it is to guess the pronunciation of a word. In English the proportion is high, in Chinese it is low. Thus English spelling represents English speech sound by sound more accurately than Chinese characters represent mandarin speech; but Finnish spelling represents the Finnish language better than either of them. The Finnish script is highly efficient phonetically, while the Chinese (and Japanese) script is phonetically seriously deficient.

So, in short, you can read accurately Finnish when you know the rules and you cannot do that that easily with English. Here is a diagram (from DeFrancis and Unger) that shows on a theoretical continuum the different writing systems, between pure phonography and pure logography.

What is says is that the closer you are to Pure Phonography, the easier to read and produce the adequate sounds. Interestingly enough, I spent most of my life believing that French was harder to read than English when it is the opposite. And believe me, as a Frenchman adopting English as my working language I have learnt my lot of words that you cannot pronounce unless you know them already. But that is another story.

So, what we discover here is that, every language is made of phonetic and semantic signs, and that the phonetic is far from perfect. Now, what about the semantic? Back to our requirements, what is important to us is the information conveyed from one person to another, the semantic. In fact, it is even worse than the phonetic aspect! What we mean when producing a sentence is different depending on the context. It is different depending on your culture (with the same words). It is different depending on your age, experience, time of the day, etc. Let’s take a couple of examples:

Suppose you are at your doctor’s waiting room with your kid. You have been waiting for a while and your child is getting bored and looking for some fun to kill the time. She is now taking magazines, tearing them apart. Then she is moving chairs making noise and disturbing everybody trying their best to read something. You take your child apart and say: “That’s enough. I am tired of you. I don’t know you anymore!” Every one of you, readers, understands that we don’t mean “I don’t know you!” but “I am ashamed and I wish people would not know we are related.”

Now take the same sentence after being cheated by someone you really counted on. Someone who is disappointing you like never before. You now say: “I don’t know you anymore!” In this case you mean something like: “I do not want to have contact with you anymore. If I ever do, I will behave like if we were strangers.”

The example I often use in my trainings is the expression “I’m going to kill you!” Clearly, this is an expression that rarely means what the words are supposed to say; which is quite fortunate! We can read the meaning in the intonation, the facial expression, the body language, the precise context when it is said, etc.

So where is this leading? It is leading to the fact that most of projects failing due to poor requirements are counting on written natural language only; which means you remove intonation, facial expression, body language and so on. Only remains words. And words are so weak at being precise!… These projects are trying to prevent the unexpected by writing to death all the details of the project when in fact, the more you write, the more inaccuracy you add to the project. This is intrinsic to natural language. There is no way you can define all the details of a software project in writing only and be accurate. So, there must be other ways to do it. And indeed there are multiple solutions. I list without specific order: use of diagramming techniques like UML, increase the communication level between business stakeholders and IT team, implement documentation reviews, produce a project/company dictionary, get workers to know each other and understand each other’s roles, remove silos and ivory towers within the project and so on. I’ll surely pick some for a future topic.

Keep in mind: natural language is treacherous and not created for understanding without adding human context. If it were the case, after all these years trying to write laws with precision, we would not need any more to refer to jurisprudence. We still do; which means we still are unable to write law and mean precisely what we mean. So why would we for software?

Let’s think about IT!