In a project, the most important element is the human part. People are forming the third side of the project triangle. To manipulate the chosen technology and to respect the selected process, you need human team members. If they don’t work well together, if they do not respect each other or if they do not target the same objective, the project is doomed.

Respecting and trusting co-workers is essential. In case of stress, instead of blaming the others for the troubles we face, we tend to collaborate and cooperate. How do we create such positive context? The answer is in knowing the others and one-self better.

In my previous articles, I have introduced the importance of cross-cultural communication (see Develop magazine #114) and the benefit of understanding what makes the others different and how to leverage on that difference. Somehow we can approach the variety of functions within the team with the same spirit. Indeed, we do not count anymore the number of times we have heard things such as: “The XXX workers know nothing about a project, look at the rubbish they produce!” Replace XXX by “Testers”, “Managers”, “Developers”, “Designers”, etc. Whoever is not in your seat are mostly incompetent and almost a nuisance. In a way, it is a miracle that the project is happening and “you” are at the centre of that success.

Of course, the reality of a project is totally different. Everyone is trying his/her best to make the project happen. No-one is waking up in the morning with a devilish smile and the intention to ruin the project! So, how is that? This is the result of a lack of empathy when it comes to others’ jobs. To achieve empathy we need to build respect and then trust. How can we achieve that?

This situation is rather common on project and we can approach it with several tools. I will introduce one of them:
The objective is to go through the team and have the team members experience the others’ jobs. Beware of the word “experience”, I do mean it. Talking forever about others’ difficulties is often vain. Only by feeling the pain in your “flesh” you will accept and remember that the others also do a tough job. To do so, you need to organise workshops around themes such as “Coding from specifications”, “Writing specification”, “Producing a technical architecture”, “Running a team meeting for agreement”, etc. During these workshops, you have to put the staff in front of the challenges that are the daily bread and butter of a chosen role and have them try to do it themselves. Some will say that you cannot ask people to feel what a developer does if you are not a developer or what a tester or designer does. This is not true. It is always possible to do so. Do not forget that your staff is intelligent, educated, experienced and most of the time keen to do well. They can definitely get it if put in the right situation. In essence, every role in the project is about problem solving. Only the tools, the context and the possible specific talent are different. But in all cases, nothing stops you from experiencing someone else’s job, at least to the point that is calling for respect. I have done it several times for several job positions and not only it is possible but it does marvels. People get out of such workshops with the right understanding and therefore a new born respect for the others. How often did I hear for instance “But to do this you would need such and such!” when such and such is only partially available and this partial info is the essence of the challenge. If you happen to be the very person providing that information, you will try harder next time and more importantly you will not complain when you are asked by your co-workers to flesh out your work, complete your information, explain the assumptions, etc. In a word, you have created “respect”. By doing so, you have totally changed the nature of your staff relationship for the good. You are on a path of money saving and respected deadlines!

There are things around us that we take for granted and don’t give much thought about. Numbers and counting is definitely one of them. We all learn how to count from very early age. We manipulate numbers very easily and beyond numbers, mathematics has given the power to change the world. But if you ask abruptly to anyone: where does it come from? Very few can answer that. I could not, until my parents, in 1995, give me this book as a present. This book has had a huge impact on me and this is why I will tell you more about it. But before starting the review, I’ll have to say that the version I have read is rather old and it seems to me much bigger than the versions available these days. In its French version (see picture with white cover available in Amazon in second hand), it was made of two books of about 1000 pages each. The editions you can now find are about half the size. Has it been shorten or is it just the editing that makes a difference? I could not tell you. But obviously the check I’ve made on the recent editions seems to show that you might have less but you’d still get plenty.

First impression

What strikes the reader when you get that book is the huge amount of information, the incredible number of topics covered in this book. The more you go through the chapters titles, the more you understand you knew nothing about numbers. There is much more to numbers than the 10 digits we daily use in occident. Humans have been extremely creative as the need to be able to count was huge. You actually cannot trade, plan or build properly without numbers. So, the number of solutions to be able to do that is huge and this is what Georges Ifrah is showing in this book.

In details

Once you start reading Ifrah’s book, you cannot stop being amazed in front of the diversity of solutions created by human beings for counting. Some solutions are extremely clever and efficient when others are kind of clumsy. In the clumsy set you have the famous Latin system using letters such as XVII. Not only it is complex to read but it doesn’t even allow making an addition properly. Amazing! Other cultures have been able extremely early in history of humanity to calculate rather precisely the distance between earth and the sun. In order to do that, you need something efficient and capable of representing huge numbers. Just that last bit is important: being capable of representing huge numbers is not that obvious. After all, for counting cows at the market, beyond a few thousands you have little needs.

George Ifrah is not only covering the different systems, he also covers topics such as bases. Why do we use a base 10? Why do others use base 20 or even 12? If 10 will easily match our fingers, 12 is another matter. I think that Georges Ifrah’s suggestion for why using 12 is brilliant and so simple. You need to get that book just for that kind of thing (I do not want to spoil the pleasure, so I let you discover). Regarding bases, the ideal basis seen by modern mathematicians is also discussed.

Conclusion

You probably get it now: Ifrah has produced an absolute incredible work. I see it as a masterpiece (and I tend to be careful with the words I use). I read that book 15 years ago and I still keep it in mind and refer to it very often. It is a definite Must Have! Do not forget that the world we live in is shaped a lot by science and there is no science without the capability of counting. By reading this book you’ll go to the very root of science, to the root of human ingenuity and cleverness. This book is a journey that one wants to take to understand our very humanity better. Saying I recommend it is not good enough. It’s a Must Have. Period!

Score:

Let’s Think About IT

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.