Representation 

“Choose your words carefully.” We have all heard that advice. It’s good advice and choosing a good representation is key to solving problems, but the general point extends beyond choosing words. Take a few moments now to divide DCXXXV by IX without translating to Arabic numerals. Go ahead. I’ll wait. 

Choosing the “best” representation for a problem depends on the nature of the problem but it also depends on your own skills and experience with a representation. If you have memorized the multiplication tables up to 99 x 99 (rather than only up to 9 x 9), you can use different techniques for multiplication than if you haven’t. If you already know how to program in FORTRAN and LISP, some algorithms will be easier to program in FORTRAN and some will be easier in LISP. But if the only language you know is R, then under most circumstances, it will be far faster and less error prone to use R than to learn another language and then use that one. 

Every representation of a real-world situation will necessarily make some features of the situation obvious and other features will be hidden or less obvious. An elevator, for instance, might say, “Capacity: 12 people.” If all of the people are wildly obese, then 12 may not fit into the elevator. The capacity sign is assuming that the people will be somewhat average. If there are 12 adults in the elevator, and one of them is holding a newborn, it won’t make much difference. If there are only 10 people in the elevator and each one has a large suitcase full of gold bullion, there may be room for all 10 to stand, but the total weight of the cargo may exceed the capacity of the elevators, snap the cable, and plummet you to your death. Remember that the next time you get on an elevator filled with folks who have suitcases of gold bullion. 

Every representation has its limitations. If you’re familiar with a field, you will hopefully learn to recognize what those limitations are. In a famous book, The Mythical Man-Month, (still worth reading, though it should be called “Person-Month”), Fred Brooks shows that such a metric as “man-month” or “person-month” has serious limitations in planning and executing software projects. Some have paraphrased his message this way: “You can’t use nine women to make one baby in one month.” According to Brooks, who had plenty of experience as a high level manager of large software projects, when management finds that a software project is behind schedule (which is quite often), there are two major reactions of management: 1) require more measurements, reports, and presentations to management and 2) hire more people. 

The issue with reaction 1 is partly that it takes time away from the managers and workers in order to make those measurements, prepare those reports and presentations, and to attend the meetings. Beyond that, it puts the focus of attention on those measurements (representations) which will only be at best, modestly correlated with what the real problems are. If, for instance, requirements keep changing, or there are incompatibilities in the requirements, measuring lines of code produced is not only useless in itself; it keeps people from tackling the hard problem. A solution to a hard problem might be telling the client that there can be no more changes in requirements. A solution to a hard problem might be resolving the incompatibility in requirements. One can count lines of code pretty easily. One can count other things like “function points” with a little more work but it doesn’t require getting into the “hard” and people-oriented problems that really need to be solved. 

Reaction 2 – adding more people – will put more “resources” on the project. You can easily count the people. You can easily count the hours they work. The problem is that a person-hour is, like the elevator capacity, an over-simplified metric. In fact, it is a much worse representation of the resources on the project than the elevator metric. First of all, studies show that even among programmers with equal training, there are often ten-fold differences in productivity. The second, and even bigger issue is that even really productive programmers who are added late to a project will have to learn about the project: the people, the requirements, and the code base. If these new people are stolen from an existing project, that will also put that project in jeopardy as well. If they are instead new hires, then in addition to all the technical knowledge that they need to come up to speed on, they will also have to learn all sorts of administrivia that will take time and brain space away from the project: how to commute to work, where the cafeteria is, how to fill out time cards. Most likely, they’ll have to attend ethics training, and diversity training, and safety training. Even worse, a lot of the knowledge that they will need to become a productive member of the team mainly exists in the heads of the very people who are doing the programming now! This means that the busiest, most productive people on the project will have to take time away from programming to spend it instead on answering questions that the new people will have. 

Even this understated the real impact however. Let’s look at that phrase I just used, “…will have to take time away from programming to spend it instead…” What hidden assumption about representation is buried in this phrase? It gets the reader to think along the lines that time is additive. If I am deeply involved in programming and I get an IM or phone call from a newbie asking me a question about the project, it might take an hour to answer. Does that mean I have subtracted an hour from my own productive programming? No. It’s probably much worse than that. Why? Because I am not a machine, but a human being. It will cost me much more than the hour to get back to the same state of flow that I was in when I was interrupted. 

I was involved for a time in looking at programmer productivity for high performance computing  using various tools and the X programming language. One of the people I interviewed put it this way: “My manager calls for an hour meeting for 10 am when I am in the middle of a complex [parallel programming] problem. He thinks he’s taken an hour of my time. For him it’s an hour long meeting. But for me, he’s really destroyed the whole morning.”  

These representational issues apply far beyond software development. For example, in the USA and in many other countries, we look at GDP as a measure of the economic productivity of the country. But how does this metric shape — or distort — our view of productivity? If a parent stays home with small children and they both love the time together, and the parent uses that time to help grow a loving, educated, productive citizen, it adds to the well-being of the country as well as that child and that parent and that family. But GDP? Nada. If instead, the parent paid money to put the child in mediocre day care, that would add to the GDP. 

Similarly, if I go to the grocery and buy a hard, tasteless tomato for myself, I will pay for the growing of that tomato, advertising it, shipping it, warehousing it, displaying it, and for the genetic alterations so that the tomato, while tasteless, is easy to transport without spoiling. Yay me! I have added to the GDP. But if I go to a friend’s house and taste a wonderful tomato, ask for some seeds or a cutting and grow my own heirloom tomato, watering it lovingly with rainwater, weeding around it, and fertilizing it with compost, I have added zero to the GDP. Yet, the tomato will give me more pleasure, not less, than the croquet balls they have in the store. 

Representation is a good thing! Humans use symbolic thinking to do many things that would be difficult or impossible without these kinds of representations. But we must remember the limitations and not confuse reality with our representations of reality. 

This is not a new phenomenon. In the American Revolutionary War, high ranking British military officers could not understand why the British navy “refused” to navigate their warships up the Bronx River to attack revolutionary positions upriver. If you’ve ever seen the Bronx River, you’ll realize why immediately. But the maps that the British brass looked at showed a navigable river! 

Yes, we need to use representation in our thinking. But we also need to think about our representations. You cannot assume that the one that is customarily used is “right” in all circumstances. People of different backgrounds and cultures will often use somewhat different representations of a problem or situation. (This is one of the advantages of diversity). However you do it, it’s worth questioning whether the way you are representing a situation or problem is optimal, or even adequate, for the problem at hand. 

Suppose you are measuring “number of user errors” that users make while using a prototype text editor. You move from prototype A which averaged 10 user errors per half hour test to prototype B which only averages 5 user errors per half hour. Yay! You’ve cut user errors in half! But what if the errors you eliminated were all fairly trivial; e.g., people with version A couldn’t figure out how to number their footnotes with Roman numerals instead of Arabic. In version B, that error, along with other trivial errors, was eliminated. But one of the new errors causes the system to crash and all the user’s work to be lost. Have you really made progress? 

All errors are not alike. All dollars are not alike. All people are not alike. Not even all tomatoes are equivalent. We constantly over-simplify and yet in some cases it’s necessary in order to deal with complexity. I don’t see how all such errors can be avoided. But it’s crucial for everyone, but especially for managers and executives, to be open to the cases where the representation that is being used has become counter-productive rather than “doubling down” on such errors. Finding and fixing errors of representation are generally harder to diagnose and fix than errors made with a representation. That is all the more reason why everyone, but especially leaders, must be open to changing the way issues are represented. 

It is no accident that dictatorships generally result in nations wherein people have both less material wealth and less enjoyment and freedom. A dictator typically refuses to admit mistakes and fix them even if it means murdering someone to make the problem appear to go away. Ultimately, this process ruins any organization. Such a person need not be a national leader. They can be a company manager, a coach, a corporate executive, or a parent. Everyone makes errors, including errors of representation. But a reasonable person is open to fixing it when new information becomes available. You can be like that too. 

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

Author Page on Amazon

————————————