Across the utter and unspeakable vastness of space
Across the everywhere of place.
Take a glance.
I know we buzz as busily as a bee
With little time to contemplate eternity.
But take a glimpse every now and then,
You might be shocked at what you see.
Look beyond the daily grind
And you will find
Millions of kinds of minds
Of creatures large and small
And that’s not all!
They are dancing each and every one!
In that great and magic dance of life!
On and on the music goes.
On and on the rhythm flows.
On and on the mystery grows.
Just because our own brief turn will end at last.
That doesn’t end that endless dance divine!
No matter how you moan; no matter how you whine,
The earth will sing and spin even when your life has passed
(So fast).
Just take a little peek and you at last will see
You change, you morph, you flash.
But, regardless of your stash of cash
You won’t outlast infinity;
You won’t outwit eternity.
Don’t plot & scheme to check & slay and fight & clash.
No, help our cousins on this great green spaceship earth.
Help make this dance more graceful, fine, & filled with mirth.
You can dance your dance without destroying;
You can do your thing without annoying.
You have a million ways to thrill
Why pick out one instead to kill?
The sun is sinking red and low
The wind begins to blow and flow
Into the pines who dance with love
Inviting air and water, dirt and sun,
To join her in her laughing life-long dance
“You too can join in all the fun!
Become a part of me and you’ll have won!”
Take the time to take a glance.
The ordinary world we live in is
Extraordinary in every single way!
Every molecule of it sings.
Every moment has its million miracles!
Take the hands on either side.
Across the world, the world is wide.
We’re divided just as far as we’ve decided we can be.
This division shows a silly decision;
Not an ever-fixed reality.
When we see the truth,
We will have won.
The truth
Is that we’re one.
————————————-
Essays on America try to make sense of current politics in America though many of the issues extend beyond American borders.
Here’s a link, e.g., to an essay about how it can be hard to change your mind.
The Myths of the Veritas is a fictional series that explores leadership, ethics, and empathy in another time and place. Our tale begins as the leader/shaman of the Veritas tribe seeks an eventual successor so she devises a series of increasingly difficult trials that mainly test empathy.
When Cat Eyes had finished reading aloud the story of The Wobby Man, she put aside what the ancients called a “book” and looked expectantly at Tu-Swift. He seemed lost in thought — tortured thoughts filled with thorns — by his visage. Cat Eyes stood and grabbed a nearby water pouch. Reading made her thirsty. She sat back down across from him. She smiled. She was happy to see him again; happy to be reunited with her parents; happy at all the things that the tribe had learned from their discovery; happy that it had taken both of them working together, with their mutual friend Suze, in order to discover how to read. The joy of Cat Eyes felt a sharp edge though because Tu-Swift seemed anything but happy.
“But, I don’t — .” Tu-Swift didn’t finish what he said to Cat Eyes because he didn’t know what he himself meant to say. Instead, he shook his head from side to side. “Why?”
Cat Eyes took his hands into her own and looked at him with love in her eyes, a love that he did not see because his head bowed down and his eyes were only upon the ground. After a few moments she put one of her hands under his chin and lifted it up. They looked into each other’s eyes and she could see that his eyes were tearing up. “It’s okay. It’s to learn from, like all the stories here.”
Tu-Swift shook his head from side to side and bit his lips. “But why?” His voice was plaintive as though he had a thorn stuck painfully under his fingernail and pled for her to remove it.
Cat Eyes sighed and asked gently, “Why what? What are you struggling with? Maybe we can work it out together. Often, life is a fight, but it doesn’t mean you have to be alone in every fight.”
Tu-Swift nodded. After a pause he said, “Why did The Wobbly Man do all that evil? And why did they let him?! Why couldn’t they see what he was up to?”
Cat Eyes nodded. “There are people who do things — evil things — such as steal children. Perhaps there always will be. But I don’t think they think of it as evil. To them, it’s their way of … living … or of having fun. They like destroying life and love in others … I guess because they cannot experience it themselves. I don’t know.”
Tu-Swift sighed. “You are right of course. Within the Veritas where I grew up, there was one such. The Wobbly Man sounds much like him. He manipulated others. He was cruel. Yet, he was such a good liar that he almost fooled our leader, the wise She Who Saves Many Lives. He actually betrayed the tribe to NUT-PI. And here’s the worst part. He got several other braves to go along with his schemes. Without ALT-R, I don’t think POND MUD or KAVANUT would have even been evil.”
“Yes.” After a pause, Cat Eyes added, “It’s much like that Red Spotted Death. It can spread from person to person. And, just as there are evil people even in societies based on truth and trust and love, so too there are people who act in good ways even among the Z-LOTZ and the ROI. It’s much like the story about the two wolves inside someone and which one you feed. The customs of the tribe can make it easy to feed the good wolf — or easy to feed the bad wolf.”
Tu-Swift let out a long sigh. He stood up and held out his hand. Cat Eyes took it and, for a time, they walked in silence. Without intending to do so, they ended up at the entrance to the now dysfunctional tunnel. They stood for a time, holding hands in silence staring at the tunnel. At last, Tu-Swift voiced what both were thinking.
“How could a people know so much as to build a tunnel through a mountain — and yet be so ignorant as to let a liar destroy their village?”
Another long silence ensued until Cat Eyes sighed and spoke again. “We still have many books to read and understand. Many books are filled with words whose meanings we have yet to understand. It appears that it wasn’t just a village here and there. The plague of evil lies destroyed everything. I know you have struggled with whether to use the fire sticks….”
Tu-Swift wondered why Cat Eyes stopped speaking. He looked at her and saw that silent tears were streaming down her cheeks. He squeezed her hand and asked gently, “What is it, Cat Eyes? Why are you so sad?”
“Actually, I was just thinking a little while ago how happy I am about so many things. Yet … we had so much. We knew so much. But we destroyed it. If the books are true, and if our understanding is correct, weapons were developed that … weapons were created that were far worse than fire sticks. Far worse. Yet, there were also treatments for every disease. But the people forgot that they were part of the Tree of Life. People forgot that they were all one. People — not everyone — but enough — just began to grab everything they could for themselves. Lying became commonplace. Once the truth meant nothing, decisions were made by power alone. That is bad enough in the Z-Lotz or, from what you told me, among the Cupiditas. But imagine that they had — not just fire sticks — but horrible weapons that could destroy many villages and all the people in them. Of course, in doing so, these weapons killed birds and butterflies and trees and no-one even seems to have noticed! Maybe … perhaps, we are not really understanding. Maybe they are just stories to prevent people from becoming what the books say that they became. Maybe.”
Tu-Swift bent down and plucked up a small flower that had grown in the cranny of the wall that held the now defunct controls for the tunnel door. He gently braided the stem into the silky hair of Cat Eyes. When he was done, he said, “Well, the tunnel is real. Yet, no-one really knows how it works. How could that be? I mean, unless there was some great loss of learning. I don’t know. Perhaps, we can learn from these stories, whether real or not, how to … how to ensure that we do not fall so far again. From what you said, it sounds…it sounds as though the people became sightless and witless. How can the people not see that they are a part of the Great Tree of Life? How can they not hear the song of the bird or the murmur of the stream? How can they not see the beauty of the trees and flowers all around them? How can they not taste the sweetness of honey?”
Cat Eyes nodded. “That is one of the main question that we — those of us who are studying the books — keep asking ourselves. But when this question is asked, none of us answers. Not yet. Each of us is hoping someone else will explain. But what comes to our ears is only the silence and the cedars sighing in the wind.”
“Tu-Swift, we are learning so much from the library we uncovered. Just as you came, I was putting the final touches on a translation of a story about Stoned Soup, Would you like to hear it?”
“Yes! What’s it about, Cat Eyes?”
Cat Eyes smiled. “Well, I’ll tell you the story and you tell me what you think it means. Here. Come sit beside me.” She patted the rough-hewn bench she sat upon. “You can watch the words as I tell them. How would that be?”
“That,” replied Tu-Swift, “would be wonderful. I love hearing your voice.” He sat beside her and took her hand in his and peered at the runes that he had helped decode. This is the story she read him:
Once upon a time, long ago, there was a village blessed with enough for everyone. The village, named Acirema, was located near ancient beautiful forests of beech and oak. The forests abounded with plentiful game. Long ago, the people of Acirema had cut down part of the forests and turned it into rich farmland capable of producing abundant food. Beyond the forests lay snow-capped mountains. From the mountains, several clear beautiful rivers ran to the plains near the village of the Acirema.
These villagers, like most villagers, had developed many customs. Among them were their shared evening feasts. Except when the weather was exceptionally bad, the villagers gathered in the evening to share a feast. They built a huge fire beneath a large cauldron. When the water finally began to boil, villagers began to contribute what they had to the community soup. Some brought potatoes and turnips; others brought large yellow squash, Jerusalem artichokes, and bright orange carrots; still others brought nettles, blackberry leaves, and hickory nuts. Others, who had been lucky at hunting or fishing or gathering eggs brought those contributions and added them to the soup. Each time the villagers made this soup, the first ingredient that they added was invariably a clean stone, though no-one knew exactly why. Many simply accepted that this was the proper way to make soup. Some theorized that the stone made it tastier. Others believed it helped the flavors circulate. Some thought it was a sacrifice to the god of the fresh mountain water, the sun, or the spirits of the forests.
When the soup was ready, everyone partook and everyone was satisfied. After the meal, they would take turns telling stories or reflecting on the events of the day. Sometimes, they would dialogue about why they began their recipe with a stone.
On occasion, strangers would wander by and they would join in the evening meal. Some of these strangers taught the Acirema new dances or songs or showed them new ways to make things. Some were strangely silent. All of them thanked them for the soup and most continued on their way after a day or two but some liked the village so much that they joined with the Acirema. Those who joined soon found a way to make their own contribution to the village and its soup. Although some harvests were sparse and some flush, the Acirema always had enough to feed everyone in the village. They worked in harmony and enjoyed life.
One hot summer day, it so happened that a fat old man wobbled unsteadily into their village. Despite his obvious extra folds of fat, he demanded a very large portion of soup. His appetite seemed nearly insatiable. He didn’t say much at his first few evening meals, but he observed carefully.
The Wobbly Man noticed that some people ate more than others. The Wobbly Man noticed that some people were taller than others; that some had blue eyes and some had brown eyes. The Wobbly Man noticed that some villagers put a large quantity of carrots in the soup and others only put in a few nuts. The Wobbly Man noticed that some people were old and some were young.
Although the Wobbly Man said little during the evening meal for the whole village, he spoke throughout the entire day, at first, only to one at a time. The Wobbly Man spoke to a strong young man thus:
“Well met, my strong young lad! You must be the strongest man I have ever seen! Surely, you are the strongest in the village! Am I right?”
The strong man answered modestly, “I may be.” He shrugged.
“Of course you are. And, yet, I know that you could be much stronger still. You are not really getting your fair share of the evening soup. Your grandfather eats as much as you do! How is that fair? I’m sure you’re a much better hunter.”
“Grandfather? My grandfather no longer walks this earth. Perhaps you saw my father? He often sits next to me.”
The Wobbly Man acted surprised. “Oh, that old man is your father. I wonder…he doesn’t seem nearly so strong as you do. Well…who knows? But anyway, he certainly eats a lot for his size. And, yet, he isn’t half the hunter you are, I imagine. I don’t really know. I’m just guessing from how little he adds to the soup.” The Wobbly Man smiled.
After a few moments of awkward silence, the strong young man said, “I’m going hunting. Do you know how to hunt? Do you wish to come too?”
The Wobbly Man replied, “Oh, no. I don’t hunt. You go ahead. And don’t pay any attention to what I said. It’s none of my concern. I like to joke a lot. That’s all. It means nothing. Sometimes a maple tree springs from an acorn, you know?”
The strong man shook his head. “No, that never happens. What are you talking about?”
The Wobbly Man replied, “No. Perhaps you are right. I’ve never actually seen that either. Well, you go hunting. Happy hunting!”
Next, the Wobbly Man spied one of the beautiful young maidens of the tribe. Long silky blond hair framed her smooth skin and her bright blue eyes. He followed her down to a nearby stream where she bathed herself. He watched with pleasure from behind some bushes. At last, she emerged, quite refreshed; she lay on a warm slab of shale to allow the sun to dry her front and back. When he judged she was about to re-robe herself, the Wobbly Man walked by casually placing himself between the young maiden and her robe.
“Oh! Well met, young maiden. I didn’t realize anyone was here. Nor did I realize it was your custom to go naked in public. I shall join you then and learn more about your ways.” In a flash, he dropped his own clothes in a pile at his feet.
The young maiden blushed and this excited the Wobbly Man even more; so much so, that his excitement was nearly visible. He strode up to her wondering whether his great weight would be sufficient to force her to do what he wanted regardless of her wishes.
“Sir, put your own clothes back on and hand me mine! You are a guest here and it will not do well for people to see you naked. They may misunderstand your intentions.”
“Oh, me, oh, my,” said the Wobbly Man. “I’m just having a little fun. Is that such a bad thing? It’s of no concern to me if you prefer other women instead of a handsome guy like me. I’m sure another young lady will be along shortly. Maybe this is where you congregate? Ah, but I’m a stranger. What do I know?”
As he spoke, the Wobbly Man reclothed himself and sauntered back toward the nearby village. Here, he spied a group of youth having a spear-throwing contest. After he spied a particularly long throw, he spoke up again.
“Nice throw! Back in my village a throw like that would earn you the right to a maiden such as the one lying naked by yon stream.” The Wobbly Man pointed in the direction he had just come. “Even now, she is quite — what is the right word? She is quite desirous of having pleasure with someone. She even begged me to have sex with her. She complained that none of the young men hereabouts were interested in wooing women. A shame really. But what do I know of your customs? But if I were younger and stronger, I wouldn’t wait so long to make my own desires known.”
The young men looked at each other and left off their spear throwing contest and ran down the path toward the river, each hoping to win the young lady’s heart.
The Wobbly Man smiled and chuckled to himself. He closed his eyes and imagined all of them forcing themselves on her. At least, he hoped that’s what would happen. If she were broken and exhausted, he would try his own luck again.
Now, a new opportunity presented itself and required his attention. The father of the young man he had spoken to earlier was sitting alone and cleaning fish. The Wobbly Man walked over and sat down on a nearby log. “Good afternoon, dear sir. I believe I spoke earlier today with your son. I’m still learning the names of the people here. What is your son’s name again?”
“Rigel.”
“Rigel! Rigel! That’s a fine name. And your son seems healthy and strong as well. I must tell you that my own son, named Junior, is every bit as ungrateful. More so. I’m sure they’ll grow out of it. That’s just the way youth are. I wouldn’t worry about it. Speaking of Rigel, where is he? Why isn’t he helping you clean the fish? That seems the least — I mean, it’s none of my business, of course, but it seems as though if he’s going to complain about you getting more of the soup than he gets, he would have a stronger argument if he did more to prepare the soup.”
The man stopped cleaning the fish and looked at the Wobbly Man. “What? Rigel said I eat more than my share?”
“What? Oh, no! No, no, no, not at all. Not in so many words.” Here, the Wobbly Man paused, tilted his head, and pretended to be thoughtful. He clicked his tongue, leaned closer to the slender old man and whispered in a conspiratorial tone.
“If you ask me, he should be very grateful that you agreed — you know — to act as his father. Not everyone I know is man enough to do that. Right?”
The fish cleaner stopped his work again and looked at the Wobbly Man with a frown. “What do you mean, ‘to act as his father.’? I am his father.”
The Wobbly Man nodded his head up and down vigorously. “Of course you are. Of course you are! You are the man who raised him. I’m sure beneath all that resentment, he has great respect for you. I’m sure he does. Right? You are sure too, right? All that resentment in his tone and so on — that’s just — he’s probably angry at his mother, really.”
Every day, the villagers of Acirema hunted, fished, gathered food, or worked their farmland. Every day, the villagers made things, observed things, added to the general well-being, the food stores, or the knowledge of the Acirema. Everyone, that is, except for The Wobby Man, who never hunted, never fished, never built or crafted anything with his own two hands.
That is not to say that The Wobbly Man was not busy. He was very busy each and every day. He told the tall people that they should received more soup because their tall bodies needed it more than short people did. He told short people that they were short because they had not received enough soup. He told blue-eyed people that the brown-eyed people thought blue eyes were a deformity and he told brown-eyed people that the blue-eyed people thought brown eyes was a deformity. The Wobbly Man set husband against wife; he set father against son; he set men against women; he set the elderly against youngsters and he set youngsters against the elderly.
At first, the Acirema remained peaceful and kept to their own ways. But gradually, just as the sand in a river bank eventually becomes sandstone or shale, the people began to mistrust each other. As the elderly began to mistrust the young people, that made the young people suspicious of the old people.
Day after day, week upon week, month upon month, the Acirema tribe grew ever more suspicious of each other. When the autumn harvest came, many kept back a good proportion of their food for their private consumption. The community soup grew thinner in consistency and lesser in quantity. The fire needed not to be so large. People often ate in silence. Instead of sitting around the fire sharing songs and stories, the people retired to their own dwellings. When the cold winds of autumn turned icy, they stopped bothering to make soup at all, at least as a group.
The Wobbly Man had left. No-one seemed to have noticed exactly when he left. He did not tell them that he was going, nor did he share why he was going, nor where. No-one noticed him walk away from the Acirema, turn back and look from afar upon the village of Acirema and smile a broad grin. His last words to the Acirema, he muttered far out of earshot of the Acirema.
I worked at IBM, all told, about 28 years. During that time, management put more and more pressure on us to make our work “relevant” to the business. In fact, the pressure was always there, even from the beginning. Over the years, however, we were “encouraged” to shorten evermore the time gap between doing the research and having the results of that research impact the bottom line. This was not an IBM-only phenomenon.
I was a researcher, not a politician, but it seemed to me that at the same time researchers in industrial labs were put under pressure to produce results that could be seen in terms of share price (and therefore payouts to executives in terms of stock options), academia was also experiencing more and more pressure to publish more studies more quickly — and to make sure “intellectual property” was protected to make sure the university could monetize your work. This was about the same time that, at least in America, increasing productivity and the wealth that sprung from that increased productivity stopped being shared with the workers.
In the late 1970’s, the “Behavioral Sciences” group began to study the “psychology of design.” For the first few months, this was an extremely pleasurable & productive group, due mainly to my colleagues. Over the next few blogs, I’ll focus on some specific techniques and methods that you may find useful in your own work.
In this short story though, I want to focus instead on some broader issues relevant to “technology transfer”, “leadership” and “management.” Even if you are or aspire to be an expert in UX or HCI or design, I assure you that these broader issues will impact you, your work and your career. I wouldn’t suggest becoming obsessed with them, but being aware of their potential impact could help you in your own work and career.
It is telling that, almost invariably, whenever I told someone inside IBM (or, for that matter, outside IBM) that I was studying the “psychology of design,” people responded by asking, “the design of what?” So, I would explain that we were interested in the generic processes of design and how to improve them. I would explain that we were interested in understanding, predicting, and controlling these processes to enable them to be more effective. I would explain that we could apply these findings to any kind of design: software design, hardware design, organizational design, and (see last post about IBM) communication design. I would explain that design was a quintessentially human activity. I would also explain that design was an incredibly leveraged activity to improve.
Looking back on it, I still think all these things are true. I also see that I missed the “signal” people were giving me that, while I thought of design as something that could be studied as a process, that most people did not think of it that way. To them, it was never the “psychology of design,” but only the design of something.
Don’t get me wrong. I agree that somewhat different skills are involved in designing a great advertising campaign, a great building, and a great application. I agree that different communities of practice treat various common issues differently. I still think it’s worth studying commonalities across domains. For one thing, we may find an excellent way of generating ideas, say, that the advertising community of practice uses that neither architects nor applications developers had ever tried. Or, vice versa.
My own academic background was in “Experimental Psychology.” We were forever doing experiments that we believed were about psychological processes that were thought to be invariant regardless of the domain. It was an axiom of our whole enterprise that studying memory for any one thing shed light on how we remember every other thing. Similar studies looked at decision making or problem solving or multi-tasking. We came to understand that there were some interesting exceptions to being able to separate content from process. For instance, it is much easier to multi-task a spatial task and a verbal task than it is to multi-task two independent spatial tasks or two independent verbal tasks.
We used a spectrum of techniques to study “design” from laboratory studies of toy problems, to observing people doing real-world design problems while thinking aloud. After about 3-4 months of very productive work, we were told that we had to make our work relevant to software development. That should be the focus of our work. We were told that this command came from higher-ups in IBM. That might have been true, or perhaps partly true.
It might also be relevant that someone in our management chain might have been the recipient of a grant from ONR which was specifically focused on software development. So far as I can tell, nothing had been done on that grant. So, our past, present, and future work could have been co-opted to be “results” done under the auspices of the ONR grant.
In any case, regardless of the “reasons,” the group began to focus specifically on software design. In one study, we used IBM software experts as subjects. Each person was given information that was geared toward a specific transformation that occurred in software development. One person was presented with the description of a “situation” that included a number of “issues” and they were asked to write a requirements document. In real life, I would hope that this would be done in a dialogue (and, indeed, in other studies, we recorded such dialogues). Absent such dialogues, what we found was that different software experts — all from IBM research — and all given the same documentation about a set of problems generated vastly different problem statements and overall approaches.
In other parts of the study, other experts were variously given requirements documents and asked to do an overall, high level system design, or given a high level design and asked to design an algorithm, or given an algorithm and asked to code a section. There was always diversity but the initial showed the greatest diversity. The initial stage is also the one that can cause the most expensive errors. If you begin with a faulty set of requirements — a misreading about how to even go about the problem — then, the overall project is almost certain to incur schedule slip, cost overruns, or outright failure.
While the vital importance of the initial stages of design is true in software development, I would argue that it is likely also true for advertising campaigns, building designs — and even true for the design of research programs. We designed our research agenda under the assumption that we had a long time; that we were studying design processes independently of specific communities of practice or the nature of the problems people were attempting to address. We assumed that there was no “hidden agenda.” Although we believed we would eventually need to show some relevance to IBM business, we had no idea, when we began, that only relevance to software design would be “counted.”
—————-
Some of our studies on the “Psychology of Design.”
Carroll, J. and Thomas, J.C. (1982). Metaphor and the cognitive representation of computer systems. IEEE Transactions on Man, Systems, and Cybernetics., SMC-12 (2), pp. 107-116.
Thomas, J.C. and Carroll, J. (1981). Human factors in communication. IBM Systems Journal, 20 (2), pp. 237-263.
Thomas, J.C. (1980). The computer as an active communication medium. Invited paper, Association for Computational Linguistics, Philadelphia, June 1980. Proceedings of the 18th Annual Meeting of the Association for Computational Linguistics., pp. 83-86.
Malhotra, A., Thomas, J.C. and Miller, L. (1980). Cognitive processes in design. International Journal of Man-Machine Studies, 12, pp. 119-140.
Carroll, J., Thomas, J.C. and Malhotra, A. (1980). Presentation and representation in design problem solving. British Journal of Psychology/,71 (1), pp. 143-155.
Carroll, J., Thomas, J.C. and Malhotra, A. (1979). A clinical-experimental analysis of design problem solving. Design Studies, 1 (2), pp. 84-92.
Thomas, J.C. (1978). A design-interpretation analysis of natural English. International Journal of Man-Machine Studies, 10, pp. 651-668.
Thomas, J.C. and Carroll, J. (1978). The psychological study of design. Design Studies,1 (1), pp. 5-11.
Miller, L.A. and Thomas, J.C. (1977). Behavioral issues in the use of interactive systems: Part I. General issues. International Journal of Man-Machine Studies, 9 (5), pp. 509-536.
——————————
Blog posts about the importance of solving the “right” problem.
As I mentioned recently, when I first arrived at IBM Research in the early 1970’s I began to work on Query By Example and other schemes to make it easier for non-programmers to interact productively but flexibly with computers. Some of the lessons learned have to do, not with my own work, but with the work of others.
At that time, some researchers labelled their work as “The Psychology of Programming.” There were many debates — and some studies — about structures, syntax, which language was better than others, etc. There were also lengthy discussions about the process that one should use for software development. Doing any kind of “controlled” experiment on large scale code development is prohibitively expensive. It is rare that a company is willing to have two independent teams build the same piece of software in order to learn which of two methods is “better.”
Of course, one such comparison would likely not prove much. It may be that one of the two teams had a “super-programmer” or an extremely good manager. Perhaps, flu broke out in one of the two teams. You would really need to study many more than two teams to properly and empirically study the impact of language, or syntax, or process. Doing reasonable-sized experiments would be far too costly and impractical. Our lab and others did do laboratory tasks in order to test one syntax variant against another and so on. The problems were generally quite small in order for the study to be practical. So, the applicability to real-world development projects was questionable.
Walston & Felix (See below), on the other hand, were able to find data on a fair number of real-world projects and rather than try to control for languages, processes, etc., they did a multiple regression analysis based on what languages, methods, etc. real projects used and what the important predictors were of actual productivity.
Personally, I learned two lessons from their study.
Lessons Learned: #1 — Sometimes, when it comes to what matters in the real world, controlled laboratory experiments have to give way to other methods such as studying “natural experiments.” Despite the many issues with trying to interpret such findings, no-one will pay for massive controlled experiments that parametrically vary programming methods, programming languages, etc. while controlling for quality of management, experience, complexity of task, etc. Multiple regression studies and in-depth case studies; ethnographic studies; interviews: all of these can provide useful input.
OLYMPUS DIGITAL CAMERA
Lessons Learned: #2 — The impact of the variables that our community of people were looking at in terms of syntax, structure, etc. were dwarfed by the impact of organizational variables. For example, Walston & Felix found that the complexity of the interface between the developers and the customers was extremely important.
DeMarco & Lister (See below) claim that, based on their decades of experience as consultants to the software development process, projects almost never fail for technical reasons; when they do fail, it’s almost always for organizational and management reasons.
That conclusion dovetails with my experience. Many decades later, working for IBM in “knowledge management,” it was amazing how many companies wanted us to “solve” their knowledge management issues by building them a “system” for knowledge sharing.
But…
Management at the company would not provide:
Incentives to share knowledge
Space to share knowledge
Time to share knowledge
Or, commit any personnel to gathering, vetting, organizing, and promoting the knowledge repository.
So — knowledge sharing was something they were simply supposed to do on top of everything else they were doing.
They did not want a computer system, IMHO; they wanted a magic system.
These experiences were part of my motivation for attempting to catalog “best practices” in collaboration and teamwork in the form of a Pattern Language. Christopher Alexander and his colleagues looked at “what worked” in various parts of the world when it came to architecture and city planning. What they did for architecture and city planning, I want to do for collaboration.
Naturally, merely creating a catalog is not sufficient. I need to have people who will read it, understand it, modify and improve it, and then promulgate it via actual use. For now, it’s free. Comments and critiques are always welcome.
—————-
C. E. Walston and C. P. Felix, “A method of Programming Measurement and Estimation,” IBM Systems Journal, vol. 16, no. 1, pp. 54–73, 1977.
In my early days at IBM Research (1970’s), we were focused on trying to develop, test, or conceive of ways that a larger proportion of people would be able to use computers. One of the major ways of thinking about this was to use natural language communication as a model. After all, it was reasoned, people were able to communicate with each other using natural language. This meant that it was possible, at least in principle. Moreover, most people had considerable practice communicating using natural language.
One popular way of looking at natural language (especially among engineers & computer scientists) was essentially an “Encoding – Decoding” model. I have something in my head that I wish to communicate to you. So, I “encode” my mental model, procedure, fact, etc. into language. I transmit that language to you. Then, you “decode” what I said into your internal language and — voila! — if all goes well, you construct something in your head that is much like what is in my head. Problem solved.
Of course, people who wrote about communication from this standpoint acknowledged that it didn’t always work. For instance, as speaker, I might do a bad job of “encoding” my knowledge. Or, I might do a good job of encoding, but the “transmission” was bad; e.g., static, gaps, noise, etc. might distort the signal. And, you might do a bad job of decoding. It’s an appealing model and helped engineers and computer scientists make advances in “communication theory” and helped make practical improvements in coding and so on.
As a general theory of how humans communicate, however, it’s vastly over-simplified. I argued that a better way of looking at human communication was as a design-interpretation process, not as an encoding-decoding process. One of the examples that pointed this out was a simple observation by Don Norman. Suppose someone comes up to you and asks, “Where is the Empire State Building?” You will normally give a quite different answer depending on whether they are in Rome, Long Island, or Manhattan. In Rome, you might say, “It’s in America.” Or, you might say, “It’s in New York City.” If you are on Long Island, you might well say, “It’s in Manhattan.” If you are already in Manhattan, you might say, “Fifth Avenue, between 33rd and 34th.”
Building on Don Norman’s original example, but based on your own experience, you can easily see that it isn’t only the geographical relationships that influence your answer. If you were originally from Boston, now on your own in Rome, struggling with Italian and homesick and someone came up to you and asked that question in American English with a Boston Accent, your response might be: “Are you joking? But how did you know I was an American. My name’s … “
On the other hand, if you’re a 13-year old boy in Manhattan — one with a mean streak — and someone asks you this question in broken English and they’re looking around like they are totally lost, you might say, “Oh, no problem. Just follow 8th Avenue, all the way north up to 133rd. It’s right there. You can’t miss it.” (Note to potential foreign visitors, most kids in Manhattan would not intentionally mislead you. But they point is, someone could. They are not engaging some automatic encoding process that takes their knowledge and translates into English. Absurd!
You design every communication. I think that’s a much more useful way to conceive of communicating. Yes, of course, there are occasions when your “design” behavior is extremely rudimentary and seems almost automatic. It isn’t though. It just seems that way. Let’s go back to our question-asking example. Suppose you work at an information booth in New York City. People ask you this question day after day, year after year. You’re seemingly giving the answer without any attention whatsoever. Suppose someone asks you the question, but with a preface. “Look here, chap! I’ve got a gun! And if you give me the same stupid answer you’ve given me every time before, I’ll shoot your bloody brains out!” You are going to modify your answer. It only seemed as though it was automatic.
When you design your answer you take into account at least these things: some knowledge that you communication about, the current context (which itself has hundreds of potentially important variables), a model of the person you’re creating this communication for, a set of goals that you are trying to achieve (e.g., get them safely to their goal, mislead them, entertain them, entertain yourself, entertain the people around you, demonstrate your expertise, practice your diction, etc.). The process is inherently creative. In many circumstances (writing, playing, exploring, discovering, partying), you can choose how creative you want to make it. In other cases, circumstances constrain you more (though likely not so much as you think they do).
Many readers think this is a classic example of a straw man argument. “No-one believes communication is a coding-decoding process.”
Well, I beg to differ. I worked for relatively well-managed companies. I’ve talked to many other people who have worked in different well-managed companies. We’ve all seen or heard requests like this: “I need a paragraph (or a slide or a foil) on speech recognition. Thanks.”
What??
Who’s the audience? Are they scientists, investors, customers, our management? How much do they already know? What are your goals? What other things are you going to talk about with them? The people who have left me such messages were all smart people. And, providing the necessary info only took a minute or two. But it critically improved the outcome. It’s not a straw man argument.
Sit-com plots often hinge on the characters doing poorly at designing and/or interpreting communications. A show based on encoding-decoding? No. What could be funny — indeed what often is shown in comedy — are people failing to do good design and in the extreme case, that can arise by having an actual robot as a character or someone who behaves like one.
People also interpret what was said in terms of their goals, the context, what they believe about your goals and capacity, what they already know, and so on. And, even though this may seem obvious, millions of people believe what advertisers or politicians say without questioning their motives, double-checking with other sources, or even looking for internal inconsistencies in what is being touted as true. In other cases though, the same people will not believe anything the “other side” says no matter what. Just as one can do faulty design, one can also do faulty interpretation.
In any case, I decided that it would be good to “show” in a controlled laboratory setting that the Encoding-Decoding model was woefully inadequate. So, I brought in “subjects” to work in pairs at a simple task about communicating Venn diagram relationships. The “designer” had a Venn diagram in front of them. “The “interpreter” was supposed to draw a Venn diagram. The “designer” was constrained to say something true and relevant. In addition to a “base” pay, the “interpreter” subjects would be given a bonus according to how many relationships matched those of the “designer.” The designer’s bonus depended on condition. In the “cooperation” condition, their payoff would also, like the interpreter’s, be determined by the agreement in the diagrams. In the “competition” condition, the designer’s bonus depended on how different the two diagrams were.
I ran about half the number of subjects I had planned to run when the experiment was ended by corporate lawyers.
What?
IBM had no unions at that time. And, they didn’t want any unions. One of their policies, which they believed, would help them prevent the formation of unions was that they never paid their workers for piece-work. Apparently, somehow, IBM CHQ had gotten wind of my experiment. People were being paid different amounts, based (partly) on their performance. They couldn’t have this! People might think were paying people for piece-work!
It hardly needs to said, I suppose, that IBM definitely tried to pay for performance. This was true in sales, research, development, HR, management, and so on. No-one in IBM would argue that your pay shouldn’t be related to your performance. That was exactly — in one way of describing it — was going on here. By the way, these were not IBM employees and each subject only “worked” for about an hour.
Basically, regardless of how irrelevant this experimental set-up might have been to the genuine concern of unions not to pay people in an insanely aggressive and ever-changing piece-work scheme, the lawyers were concerned that it would be somehow misrepresented to workers or in the press and used as evidence that IBM should unionize. In a way, the lawyers were proving the point of the experiment in their own real-life behavior even as they insisted the experiment be shut down.
Lessons Learned: #1 Corporate lawyers are not only concerned about what you actually do or how you represent your work; they are also worried about how someone might misrepresent your work.
Lessons Learned: #2 Even when constrained to say something true and relevant, ordinary people are quite capable of misleading someone else when it’s to their benefit and considered okay to do.
It is this second aspect of the experiment that I myself felt to be “edgy” at the time. Sure, people can mislead, but I was providing a context in which they were being encouraged to mislead. Was that ethical? Obviously, I thought it was at the time. On reflection, I still think it’s okay, but I’m glad that there are now review boards to look at “studies” and give a less biased opinion than the person who designed the study would do.
I view the overall context of doing the study as positive. As adults, these people all already knew how to mislead. I was letting them, and many other people, know that we know you know how to mislead and we’ll be on the lookout for it.
What do other people think about studies wherein the experimenter encourages one person to deceive another?
———————-
References published literature that describes some of the research that was done around that time.
Malhotra, A., Thomas, J.C. and Miller, L. (1980). Cognitive processes in design. International Journal of Man-Machine Studies, 12, pp. 119-140.
Carroll, J., Thomas, J.C. and Malhotra, A. (1980). Presentation and representation in design problem solving. British Journal of Psychology/,71 (1), pp. 143-155.
Carroll, J., Thomas, J.C. and Malhotra, A. (1979). A clinical-experimental analysis of design problem solving. Design Studies, 1 (2), pp. 84-92.
Thomas, J.C. (1978). A design-interpretation analysis of natural English. International Journal of Man-Machine Studies, 10, pp. 651-668.
Thomas, J.C. and Carroll, J. (1978). The psychological study of design. Design Studies,1 (1), pp. 5-11.
One of the studies I conducted at IBM Research in the mid 1970’s was part of an effort to do “Automatic Programming” — a department under Pat Goldberg. The first level manager I worked with was Irving Wladawsky (later Irving Wladawsky-Berger). His group wanted to develop a system that would allow the owner/operator of a small business to type requirements into a computer in English (or something English-like) and have the system itself produce RPG code to run the business so described.
The underlying motivation from an IBM business perspective was that many small businesses could well afford a computer to do inventory, fulfill orders, etc. but they couldn’t afford to hire programmers to create such a system from scratch. The small business owner in the mid-1970’s did not program! Yet, for the most part, they understood how their business worked. The notion was that a natural language understanding and generation program could dialogue with the user/owner and through that process, understand their “business rules.” No costly programmers needed!
An interesting side note: at that time, we were told that IBM corporate forbade us to use the terms “Artificial Intelligence” or “Robotics” to describe our work because some PR firm had determined that these terms were too scary for the general public. So, IBM had research in “mechanical assembly” but not “robotics.” We had work in character recognition, speech recognition, handwriting recognition, automatic program generation, and compiler optimization. But no work in “Artificial Intelligence.” (Wink, wink, nod, nod).
Labelism:Confusing a thing with the label for that thing.
Another interesting side note: I worked at IBM Research for a dozen years; started an AI lab at NYNEX where I worked another 13 years; came back to IBM Research and several years later found myself working on the same problem! We were still trying to make a system to allow small businesses to generate their code automatically. In my second iteration, rather than using natural language, we were trying to make the specification of business rules in a graph language that was intuitive enough for business owners. This was a different approach, but trying to address the same underlying desire: to bring computing to small business without incurring the heavy costs of programming and maintenance.
Let’s return to iteration one — the natural language approach @ 1975. Well, one issue was that no-one had a natural language program that even approximated being able to do the job. So…how to study people’s interaction with a system that doesn’t exist?
We used an approach that my colleague Jeff Kelly called the “Wizard of Oz” technique; viz., use a human being (in this case, me) to simulate how the system might work and record people’s behavior. In this way, we could discover many of the issues that such a natural language programming system would have to deal with. I had already had plenty of experience interacting with a computer; and I had acting experience. I could “play the part” of a computer fairly well as I typed in my questions and answers.
IBM Research in Yorktown had roughly a thousand people including not only scientists, programmers, and engineers but also a number of business people (who did not know how to program). I knew some of them from playing tennis and table tennis and we used those folks as initial subjects. What did I find? Good news and bad news.
Dealing with natural language is tricky for many reasons. One of those reasons is that English, including the English that people normally use to describe their business, is filled with words that have multiple meanings; e.g., “file”, “run”, “program”, “object”, “table”, etc. But here is the good news: although it’s true that many English words have many meanings, when these business people described business procedures, almost all of the lexical ambiguity vanished! The program to understand business English would not have to distinguish between a business file and a nail file; it wouldn’t have to worry about distinguishing a run in baseball or a run in stockings from a run of the payroll program; it wouldn’t have to distinguish between the table in a relational data base and the table in your dining room. The domain would mainly constrain! That’s the good news.
The bad news was dialogue management. How can the machine recognize a misunderstanding and how can it correct it? To make matters worse, while business people were fairly consistent in the way they described how their business ran, they were not consistent in how they talked about the communication. If a human being senses that another one is misunderstanding, then, depending on context they might: raise their eyebrows, say “Huh?”, “Come again?”, “What?” “I think I lost you.” “WTF?” “Are you kidding?”, “We’re on different wavelengths,” “I don’t get it.” “But…wait.”
Sometimes, these are referred to as “meta-comments.” Here’s a simple example that took place in the study.
One of the business people told me about various discounts. I had assumed (playing the part of the computer) that he was talking about discounts for items that were being discounted due to inventory management. I recorded all the various percentages and so on. Then, he said, “Now, we also give discounts for various items.”
At that time, most natural language systems of that era simply ignored words like “now” and “also” in this context. Stepping out of my role as a “computer system” and thinking about from the perspective of a human conversational partner though, these words are crucial! What it signals is a change in topic. In the larger context of our conversation, it shows that everything that had just been said, which I thought had been about item discounts, was not about item discounts!
This is just one example, but there were many more. In my more recent experience interacting with various computer dialogue systems, being able to recognize the signals of miscommunication and being able to repair misunderstandings is still not very well-handled more than four decades later.
I’d be interested in any pointers you have to a system that you think deals with meta-communication in a natural and robust manner. I do not think that it is beyond the pale of possibility. The general categories of the ways that people misunderstand each other is not infinite. John Anderson developed excellent tutoring systems for LISP and geometry and those systems worked something like human tutors in that, the tutor inferred the mental model of an individual student and focused instruction on correcting any misconceptions. My intuition is that a generic system built with equal complexity could deal with most of the issues as well as the average human being deals with them; i.e., imperfectly.
—————————————
Lessons Learned: #1 You can test aspects of a system even before it’s built or even completely defined. One method that has been used many times: “Wizard of Oz.”
Lessons Learned #2: Language used by professionals to talk about their domain is much more constrained in terms of lexical ambiguity than is language when considered by all native speakers.
Lessons Learned #3: People in “our culture” (i.e., US business culture) do not have an agreed upon and consistent vocabulary for talking about communication nor a consistent process for dealing with them.
Lessons Learned #4: Speaking of communication errors, I don’t recall why, but it was about this time, that I realized that my notion about how research results would be transferred to other parts of IBM was a complete and utter fantasy. I hadn’t articulated it, but it was basically that I would do research, write the results up for publication in scientific journals for an academic audience and publish Research Reports which would be eagerly consumed by anyone who needed to know. I’m not proud of this. LOL. But that’s really kind of how I viewed it. And, then, after a few years, I realized that it really mainly came about through relationships. That was something that people had been showing me all my life, but which I don’t think anyone ever stated it explicitly enough.
This is part of a series on experiences in my career in Human Computer Interaction and some lessons learned.
I joined IBM Research on the winter solstice of 1973. I had earned a Ph.D. in Experimental Psychology from the University of Michigan and for the previous few years, I had managed a research project at Harvard Medical School on the “Psychology of Aging.” At the time, I was married and had three small children. I mention this because I was funded by so-called “soft money” which basically meant that my salary depended on a research grant. I helped write a renewal of the grant but the decision was “deferred”; that is, it was neither funded nor unfunded. Then, it was deferred again. This meant that if the grant were not funded, I would only have a few weeks to find a new job. That seemed far too short so I began to look other places for a job.
Lessons Learned: #1 If you want continuity of personnel in your laboratory, make sure you have overlapping and multiple grants or other sources of income.
In this case, the grant actually was ultimately approved, but by that time, I had already agreed to join IBM Research. That turned out to be fine, by the way. It was a wonderful place to work.
One of the reasons that I got the job at IBM was that I already knew something about computers. I had taken several computer science courses in grad school along with the needed psych courses. More importantly, our “Psychology of Aging” study was run by a PDP-8 and I had programmed the computer to run our suite of experiments and to do data analyses on the results. I had taken a week-long course at DEC in Maynard, Massachusetts on the assembly language, another week-long course on the machine language, and another week-long course actually tracing the circuitry with a probe and oscilloscope. I felt I “understood” the PDP-8 at a fairly deep level.
At IBM, I did not have that familiar machine. Instead, I was connected to a mainframe via a dumb terminal. The first day at IBM, I got my userid and tried to log on to APL (A programming language I had not used before). I tried following the manual but I could not seem to get logged on. After hours of trying, I finally gave up and went down to the computer room and found someone willing to help. I showed him the logon instructions I was trying to follow and he immediately said, “Oh, yeah, that doesn’t work any more. We changed that months ago. Here’s how you need to do it now.” The manual I had may have looked new, but it was out of date.
Lessons Learned: #2 Manuals can be wrong. These days, most are online. But they can still be wrong.
Lessons Learned: #3 Someone who knows how to do something can save you hours with a few minutes of their time.
Of course, it’s more respectful, efficient, and a better learning experience if you can figure it out on your own. But sometimes you can’t. My stumbling block was not due to an error in logic, or a lack of in-depth knowledge. It was simply that the computer center administrators had changed something arbitrary so that the documentation I was given about how to log on for the first time was no longer accurate.
In order to teach myself APL, I wrote a very small program to “predict” how long I was going to live “based on” some behaviors that I was interested in controlling. My main goal was to learn APL. My secondary goal was to motivate myself, for instance, to exercise more, lose weight, and not drink too much alcohol. I had no intention or pretensions of making this prediction “accurate.” If I had been doing a consulting gig for an insurance company setting life insurance rates, for example, I would have given far more attention to see precisely what the real data were and incorporated many more variables into the regression model.
by the way, to a more accurate model than the one I used, but it’s still simple to use. Note that my goal was to motivate myself and so I intentionally exaggerated the impact of those behaviors I was trying to change. I had programmed it. I knew how “bogus” the calculation was — nonetheless — here’s the interesting thing though:
Lessons Learned #4: Even an over-simple model that the user knows is over-simple can still motivate change.
At last we come to the actual project I worked on — the usability and learnability of Query By Example. One of my colleagues, Moshe Zloof, invented the language for relational data bases. He had designed the language but not yet implemented it. I did not immediately test the design; first, I sought to understand it. In seeking to understand it in depth, prior to testing it, the two of us had some sense-making discussions. Moshe improved the design; in particular, our discussions uncovered some ambiguities and inconsistencies that were not at all obvious when he simply gave talks about the design. This brings me to the next lesson learned which has proven true in nearly every study of early stage designs that I’ve been involved with over the course of five decades.
Lessons Learned #5: Don’t just accept a surface description of something; understand it as deeply as you can before designing a study.
In this particular case, it was possible for me to understand it in some depth. Relational data bases and second order logic are things I was capable of understanding. If it had been an interface to running a nuclear reactor or using the artificial heart that Moshe had designed earlier in his career, that would have been a much more difficult task for me.
I wanted to understand, not just the “logic” of Query By Example, but also possible contexts of use. For instance, my manager & I visited Burlington, Vermont to talk with IBMer’s who actually used query languages to understand what was happening in chip production lines. At one point, a particular production line that had been producing nearly 100% perfect chips starting having a much higher error rate. Using their query facility, they were quickly able to diagnose the cause of the change which was a supplier of one of the raw materials using a different source. In turn, this meant a slightly different profile of trace impurities in the substrate. Of course, this is only one example, but to me, understanding something in depth means not only understanding its internal logic but also understanding real users, their real tasks, and their context of use.
I won’t go into all the details of the pencil & paper study or the results. High School students and then college students were taught the basics of the language and then given a simple relational data base and a set of questions stated in English which they had to translate into Query By Example. Briefly, the bottom line was that Query By Example was easy to learn and easy to use. However, there were still questions that people had difficulty with. In analyzing the data and doing some further experiments, the difficulties that people tended to have, stemmed not so much from Query By Example per se, but from what I much later came to call “labelism” — that is, confusing a label with the thing that label refers to.
Here’s a simple example of the type of confusion we saw. In Query By Example (and other query languages) there is usually an OR operator and an AND operator. (These operators can be important for doing advanced queries with search engines as well). If you are interested in getting a list of pets you might adopt and you’re willing to adopt dogs or cats, you might ask for “cat OR dog.” If you only want long-haired cats, you might ask for “cat” AND “long hair.”
English, however, can be tricky.
If you and I (as opposed to you and a query language) are having a conversation, you might say, “I hear there are many pets that need to be adopted.”
I say, “Yes, there are all kinds of pets. There are snakes, dogs, turtles, rabbits, cats…”
You say, “Let me stop you right there. I’m only interested in adopting cats and dogs. Those are the only animals I’d want to adopt.”
See what you said there? You exact words included: “…cats and dog.” If you put “Cats AND dogs” into a query against the data base of available pets, however, you will get the null set (that is, nothing) back. There are no animals who are both cats and dogs! (Though my part Main Coon cats do play fetch like dogs).
When people were presented with an English statement that included the English word “and” — regardless of the actual syntax and context, some of them had difficulty using the OR operator. If instead, the query in English had set up like this: “Oh, I don’t want reptiles. I’d be happy with adopting a cat or a dog, however” then, they’d have no problem translating it into the OR operator in the query language.
Lessons Learned: #6 Sometimes the difficulty people have in using a product, a service, or a prototype is not due to the interface details but with the structure of the task, their background, and their training.
By analogy, you will not allow me to beat Nadal or Djokovic at tennis by giving me a better tennis racquet! (Although if you gave one of them a toothpick for a tennis racquet, I might have a shot).
That sounds obvious and even absurd, but I promise you, some companies get so greedy that they want you to design a system that allows people who do not understand the task and have minimal background and training to nonetheless be able to perform that task.
One example you may have run into is having “help desk” personnel who have no understanding of a product go through a script to help you “solve your problem.” Sometimes, it works. But many times it doesn’t. When it does not work, you might not be able to “fix” the system by making the interface to the scripts easier to use for the help desk folks. The problem is much deeper (in some cases). Yes, a really bad interface can make it difficult even for a really knowledgeable and capable person to do the job. But often, even a really great interface cannot always substitute for actual expertise.
petersironwood 