It’s All About Communication

Note: This was originally chapter 13 of my book, UML Applied: A .NET Perspective from Apress. My editor and my tech reviewer read it; and both said, “We like it; but what does it have to do with UML?” So I came up with a more on-topic closing chapter. But I still like it. It sums up my view of the software development profession quite nicely. So I thought I would share it here.

Somewhere, deep in our prehistory…

A man tells a story, a story of a hunt. Perhaps it’s a hunt he’s planning. Or perhaps it’s a hunt that just took place, and he’s telling the tale. In telling his story, he draws Figure 13-1:

Figure 13-1: The first recorded UML diagram?

Figure 13-1: The first recorded UML diagram?

Regardless of whether he’s telling the past or planning the future, he has built a model of “How we kill the prey.”

From these simple pictorial models, we moved to pictograms… and cuneiform… and eventually to alphabets and written words. With words, we can model much more abstract concepts than our hunter ancestor could — such as “abstract concepts”.

Elsewhere in our prehistory…

A man looks at a set of things that are important to him — perhaps it’s livestock, perhaps it’s weapons — and can see at a glance that all the elements of the set are there.

But soon, the man grows more fortunate. He gains more livestock, and more weapons. And as he gains more, at some point he can’t tell at a glance that all the items are there. Remember our 7+/-2 rule: past a certain point, the elements of the set blur together.

So the man finds a way to keep track of the items. He recognizes that he can associate the individual fingers of his hands with the individual animals or weapons. And he knows his fingers, and how many he should have, and which finger corresponds to the last item; and so he knows how many items he should have. He can match the fingers to the items; and when the match is correct, he knows all the items are there; and when the match is incorrect, he knows there are missing items (or extra fingers).

And thus, with his fingers he has built a model, a symbolic representation of the items that concerned him. And when he grew wealthier yet, and the number of items grew beyond the limits of his fingers, he and his intellectual heirs invented new models: counting sticks… and tally marks… and Roman numerals… and Arabic numerals…

And all of these counting methods were models or symbols of things in the physical world. But along the way, we developed more abstract concepts: operations that could be performed on the numbers. We can add to or subtract from a number, without adding to or subtracting from the items themselves. And thus, we can have numbers that don’t represent any physical items, but simply represent the abstract concept of “count” itself. And along the way, we invented arithmetic… and zero, which represents an absence of things… and rational numbers that don’t represent any count of things, but rather the ratio between things… and mathematics… and negative numbers, which represent a dearth of things… and irrational numbers, which represent the numbers between ratios, numbers which cannot be associated with a physical count of things at all, yet which often represent underlying aspects of physical reality (π, e)… and algebra… and imaginary and complex numbers, which represent vector quantities which cannot be graphed on a number line without extending that line into a new dimension… and varying numerical bases… and mathematical logic… and accounting… and trigonometry… and statistics… and probability… and higher mathematics, where we question or even dispense with the matter of number itself…

And all of these advances in mathematics are powerful models, letting us express concepts only distantly related to “How many goats do I have?” — concepts that underlie everything around us, from our understanding of the laws of physics and chemistry, to our understanding of rhythm and meter and tone in music, to our engineering skills that produced the laptop on which I type this sentence.

Somewhere inside my laptop…

There is a tiny zone of silicon, with a tiny doping of impurities which render that zone a semiconductor. And at any given moment, that zone is in a charged state or an uncharged state, depending on the flow of electricity through my laptop and through components of the system and through paths shaped by wires and by billions of other tiny zones of semiconducting silicon. And we look upon the charged state and the uncharged state, and we choose to call the charged state “1” and the uncharged state “0”. This is simply an arbitrary choice, not a physical reality. It’s a symbol we could define any way we chose.

And thus, the state of that tiny zone of doped silicon is a model of a model: a physical representation of the concepts of “0” or “1”. The tables are turned: instead of our symbols representing reality, we manipulate reality to represent our symbols. And then, our technology lets us string these physical symbols into sets to represent larger and larger numbers — and with IEEE floating point format, numbers beyond simple counting. Yet despite the size and power of these number formats, they are still at base models of models: physical symbols to represent the abstract concepts of numbers. They are silicon “fingers” (and we even call them “digits”, just as we do fingers).

Somewhere in the field of psychology…

Psychologists study how our brains work, how we think and how we communicate what we think. And one underlying mechanism stands out: creating and manipulating symbols and models.[1] We have symbols and models in our heads that represent to us concepts in the real world and concepts in the abstract (such as “concepts in the abstract”). And we manipulate these symbols, and we create new symbols for new concepts. And in fact, if we do not have symbols for something, we cannot think about that something. These symbols, these concepts, form our mental models of the real world, and of ideas. From these, we can build larger, more useful models, such as theories and skills and bodies of knowledge. Armed with these larger models, we can understand and manipulate the world around us. And however imprecisely, we can communicate and share these symbols.

Elsewhere inside my laptop…

As I sit with this laptop in my lap, and I press this key — this very key, “q” — a contact closes under the keyboard, and a gate opens, switching from a “0” state to a “1” state. This allows a signal to be sent to the CPU, and from there to be routed to a particular chunk of software. That software looks at the signal, and translates it to a specific numerical code — 112 — that we have chosen to associate with the letter “q”. Like our physical symbols for “0” and “1”, this is an arbitrary symbol we have chosen to have the precise meaning, “q”. This doesn’t mean that 112 “is” the letter “q”. It means that 112 represents the letter “q”, and we have agreed to this precise representation, so that when I press this key, you see something that represents to you, “q”. Ultimately, we have manipulated physical things that are symbols and representations — models — and by sharing these models, we can exchange ideas. The models have become so powerful and so precise and so flexible that we no longer see the models at work. We see the thoughts themselves.

Somewhere inside my head…

I have a set of symbols inside my head: a set of thoughts, a set of ideas, a set of concepts that collectively can be called a model. This model represents to me a set of equations and mechanisms by which one can simulate a spacecraft and control that simulation on a voyage from the Earth to the Moon. I can enjoy the beauty of these symbols, and I can enjoy the concepts, and I can play with them, and I can write them out. And I can see that these symbols do truly represent (to the accuracy that I care, since I’m not a rocket scientist) the process of traveling to the Moon and back.

Somewhere inside your head…

And if I teach you the same symbols, and if we share enough common symbols and models, you can do the same thing. This is the purpose of the tools we call “language”: to allow me to convey the things that I know in such a way that you know them as well, and can apply them, and can build upon them and communicate your new ideas back to me and to others. As I quoted him in Chapter 3, Stephen King is right: writing is telepathy.

Once more inside my laptop…

But now, with software, we have a new construct, a new kind of tool. It has a character like traditional machines: regular, precise application and replication of mechanical and physical laws toward a particular purpose. But it has a character like language. Being made entirely of malleable physical symbols which can represent whatever we want them to represent, it is more than a traditional machine: it is an Idea Machine, a Concept Machine, a Symbol Machine. And since those are the building blocks of how we know and how we think, it is a Knowledge Machine and a Skill Machine. I can take the “Lunar travel” symbols from my head, and I can express them not to you, but to software that resides on your computer. And if I express them sufficiently thoroughly and correctly and precisely, you too can go from the Earth to the Moon, but without having to learn the symbols and models that I know. Instead, you need only learn a much smaller set of symbols for telling the software to do what I know how to do.

The Point (At Last!)

As software developers, our job has never been about technology. Our job has always been about expressing symbols and ideas and knowledge and methods in precise physical symbols so that other users can reuse and apply those symbols and ideas and knowledge and methods without having to master them themselves — or if they do master the symbols, without having to go through all the rigor and discipline and effort of applying them for themselves. All they have to master is the effort of telling the software to do what we have already mastered.

And the other side of our job has been to master that which we don’t know. We may be skilled at precise expression of ideas in physical symbols, but that doesn’t make us skilled at Lunar launches and color science and financial forecasting and the myriad other symbols and ideas which users want expressed in software. So we have to learn how to elicit those symbols and models from those who have them, but who lack our skills in precise expression through software. In a sense, we’re translators between mental symbols and physical symbols, adding in our own mental symbols to provide an intermediary layer to allow users to make use of the physical symbols.

In other words — and you had to know that this was coming — it’s all about communication.

And there’s a bit of irony for you. Our field — where our entire job is precise communications — is infamous for practitioners who are perceived to be short on communications skills. And in fact, nothing could be farther from the truth: to have any success in software at all, you must be very, very good at precise communication, at taking an abstract set of symbols in your head and precisely communicating them to the software in such a way that the software “understands” what you understand.

So if software is all about communication, how has it come to be seen solely as a technology job? Indeed, how has it come to be dominated by technology fanatics who (in many cases) do have something of a problem with unstructured, imprecise communications? Why do some developers have such trouble with the nuance and the double meanings and the give-and-take and the vagaries of human communications?

Well, one reason is that for most of the history of software development, communicating with the technology has been hard. Very hard (though getting easier). It requires an exceptional degree of precision, and therefore it requires specialized skills not found in the general populace. As I mentioned in Chapter 2, you’re weird: you handle precise communications in ways that most other people do not. This tends to set us apart. And perhaps that setting apart attracts people who are better at technology than at communications. Perhaps the time spent with precise technological tasks even causes atrophy in our other communications skills, since people usually do better at that which they practice a lot, and worse at that which they neglect.

Another reason is that in the past, limitations of the hardware strictly constrained what we could and couldn’t communicate and also put a premium on mastering obscure technical tricks and creating new technical tricks to live within the limitations of the technology. The software developer culture evolved in circumstances where technological prowess was essential in order to communicate at all.

And yet another reason: the small size of projects that could fit within those limited environments was often a small size which could be mastered by someone who could communicate his or her ideas well without needing recourse to communication with others. A large number of projects were small enough and simple enough to resolve primarily through technological prowess.

Well, as I tell my students, there are no simple problems left. Yes, this is a bit of an exaggeration; but as a practical matter, the simple problems have been solved. Hardware today has grown so powerful as to have no meaningful comparison to the hardware of a generation ago; and yet the software problems of today strain that hardware to its limits, and there’s always a backlog of problems we’d like to solve as soon as the hardware catches up. Today, no one hires a software developer to solve simple problems. They hire us for the hard problems… the really complicated problems… the problems they don’t entirely understand themselves… the problems for which requirements are hazy, and success cannot be clearly defined. And they’re counting on us to clear away that confusion, to help them define what their needs are and what success means. They’re counting on us to communicate with them because they don’t know how to communicate with us. We must communicate with them and for them, leading them through the communications process to lead to the precision that the software requires.

In other words, now and for the foreseeable future, I believe that communication will be the key software development skill. I don’t want to discount technology skills, because there are always new technological frontiers to master (like .NET today); but without communication, we’ll fail to apply the technology in ways that matter. We have to communicate with our users, because we need to know what they need, how to accomplish it, what skills we must master to accomplish it, and how to recognize when we’ve succeeded. We have to communicate with our users in another way, through our user interfaces that allow them to access and command our software. We have to communicate with each other, because the problems are too large to solve in isolation. We have to communicate with future maintenance developers who must carry on our work when we can’t. We have to communicate with mentors and educators and experts (perhaps in a disconnected fashion, through their lessons and books and examples and presentations) to learn the new domain skills and new technology skills we must master to address user needs. When we ourselves become mentors and educators, we have to communicate to our students and readers by writing our own lessons and books and examples and presentations. We have to communicate to testers, so that they know what and how to test, along with how to recognize success or failure. We have to communicate with documenters, so that they know what to explain and how they will communicate it to the users. We have to communicate with marketers and sales personnel (yes, even them) so that they understand what we can and can’t deliver. We have to communicate with managers and executives to explain what they can and can’t expect from the technology within constraints of time and resources.

And we have to precisely communicate with the software and the other technology, instructing it to carry out the knowledge and skills we have mastered. I sometimes call this “shipping our brains in boxes”. While the metaphor is a bit gruesome, the idea is key: that software installed on my customer’s machine is a proxy for my brain, sitting there and doing for that user what I could do myself if I were there – only doing much of it faster than I could do myself (and more accurately, because software is more precise and repeatable than humans usually are). And besides speed and accuracy, there’s leverage: that software proxy for my brain can be installed on hundreds or thousands or more computers, helping far more users than I could ever help in person. We’re not just working with technology, we’re communicating with it, teaching it the things we know and then replicating our knowledge across the user community.

So that’s my conclusion, one final time: it’s all about communication. And while UML isn’t the answer to your every communication need (for instance, I thought about writing this entire chapter solely in UML diagrams; but the abstract nature of diagrams just wouldn’t express the precise thoughts I wanted to convey), I hope that I’ve shown it to be a powerful set of graphical tools for conveying complex ideas and relationships so that you can more easily communicate the skills and ideas from your users and experts to the software so that your users can apply them. Today, many UML tools will also produce the structure of your code directly from the models. In the future, UML will become a programming language, a tool for communicating with the technology directly. (Some UML tools like Compuware OptimalJ and ILogix Rhapsody already do this in certain niches.)

So UML is a valuable way to express yourself, both to people and to machines. It’s a new technology skill that will help you to apply all of your other technology skills, once you master it. Practice UML and apply it, not just by yourself, but as a means to communicate with your fellow developers and your users and everyone else with whom you must communicate. I hope that with time, UML can do for you what it has done for me: speed and smooth your communications so that you can solve more complex problems more successfully.

[1] Marcia Wehr, Ph.D., Mastering Psychology, “THINKING AND LANGUAGE”, Dr. Wehr provides an excellent introduction to psychology, as well as a good basic description of software development: “When we face a mental challenge in which there is a goal to overcome obstacles, we are engaging in problem-solving. Generally we use a common method of problem-solving. We 1) identify the problem, 2) define the problem, 3) explore possible plans or strategies 4) choose a strategy 5) utilize resources to act on the chosen plan 6) monitor the problem-solving process and 7) evaluate the solution.” That sounds like the basic outline of all software development processes.

Doctors are the Stupidest Users!

Note to doctors: No, I don’t really mean that title. I use provocative titles to get attention and capture an attitude. What? What are you doing? You’re going to stick that thermometer where?

Doctors are the stupidest users. If you’ve ever had to write software for doctors, you’ve discovered this: the phrase “RTFM” was made for doctors. They just can’t be bothered to read even the simplest help docs. They can’t bother to learn even simple tools that a bright grade-schooler can master.

OK, that’s the programmer perspective. Now let’s look at it from the doctor’s perspective. On her desk is a small mountain of medical journals she needs to read to keep up with her specialty.

Next to those is a small mountain of textbooks for the new specialty she’s trying to learn.

Next to those is a small mountain of new regulations and guidelines she must comply with to maintain her license.

Next to those is a small mountain of insurance guidelines she’ll probably never have time to read but should if she wants to make sure she’s charging within guidelines.

Next to those is a small mountain of insurance paperwork that demands her scarce attention. She has no time for it; but if she doesn’t keep up with it, patients may be denied treatment that would’ve been approved if she had.

Next to those is a small mountain of accounting statements that she’d rather not bother with, but has to if she wants to pay her student loans and malpractice insurance.

And next to all of those is a large mountain of patient histories, test reports, specialist reports, and hospital reports she needs to keep straight in order to treat her patients.

And somewhere, buried under all of those papers, are a few pictures of the family she hopes to see once or twice this week.

And along comes this programmer person who says, “What’s the deal? This is easy! Just read this, and this, and then try this, and learn this, and look at this, and it’s easy! You’re a doctor. You’re supposed to be smart. This should be easy!”

After she schedules the programmer for an emergency barium enema, the doctor goes back to her work.

This is part of the reason (by no means the entire reason) that there’s a profession of Medical Technician. These people’s responsibility, in part, is to be the doctor’s user interface to programs that the doctor just has no time to master. They have time to specialize in arcane software. They usually have more technical experience.

But really: should it be this way? Not that I want to put Medical Technicians out of work; but shouldn’t the programmers spend more effort understanding the doctors and their needs, rather than requiring the doctors to understand programs and programmers?

For years, I’ve spoken and taught about a principle I call Conservation of Complexity. For any given task, there’s a minimum complexity required for that class. You can’t make it less complex. (But trust me, some idiot can always make it more complex…) If I’m automating that complexity, I take some of that work onto myself, and leave some for the user; but no matter what I do, I can’t reduce the complexity below the minimum. And being lazy by nature, I’ll want to do the minimum necessary to meet the requirements: minimum complexity for me, and let the user do the work.

But we can cheat! We can’t reduce the complexity of one instance of the task; but we can reduce the complexity of multiple instances, especially when those instances are performed by multiple users. In so doing, we can reduce the net complexity in the system.

Let’s say the user and I split the complexity, C: I get 0.5 C, and he gets 0.5 C. Now if 100 users do the task 100 times, we have:

Cnet = 0.5 C + 100 * 100 * 0.5 C = 5000.5 C

Cave = Cnet / n = 5000.5 C / 10000 = 0.50005 C

So we’ve cut the complexity in half. That’s great, right? That’s why we write code, right?

But suppose some idiot — i.e., me — didn’t make that app very usable for the user. Oh, it’s easier than working by hand, or I won’t sell any copies; but say it’s 0.8 C. In that case:

Cave = 0.80005 C

So I took an easy way out. The system is still less complex on the whole. We’re still winning, right?

But now, let’s go the opposite way. Let’s say I put in the extra effort to reduce the user’s work to 0.2 C. And let’s assume this takes me a simply ghastly effort, 2 C. That means that:

Cave = 0.2002 C

By me working twice as hard, the system as a whole works roughly 80% less.

Now these numbers are just examples, of course. But I think they make my point: if all I worry about is getting code out the door, I may not work hard; but my users have to work a lot harder. Too often, we programmers see our perspective too clearly, and the other guy’s perspective too dimly. (In other words, we’re human.) But the smarter thing to do is to put forth the extra effort to reduce the user’s complexity. Because after all, there’s money to be made in reducing your user’s workload!

I’m reading Alan Cooper’s The Inmates are Running the Asylum; and with practically every page, I’m reminded of Conservation of Complexity. And of the doctors.

Also see Joel Spolsky’s discussion on mental models. He approaches the same idea: the programmer has a mental model of how the code works; the user has a mental model of how the code works; and great software results when the programmer’s mental model is very close to the user’s. It’s easier for a team of motivated programmers to change their handful of mental models than to change all those users.

Quantity IS Quality

On a mailing list where I hang out, a participant recently said (paraphrased): “He believes that popularity proves quality. I believe that there is almost no correlation between quality and popularity.”

We hear this sort of thing all the time. There’s an implication among self-appointed elites that “the masses” — i.e., everyone who’s not them — just can’t recognize quality. It’s assumed that “popular” is proof that something is bad. You see this attitude in film snobs who insist that an Oscar nomination for The Return of the King is some sort of travesty, because the film is a popular fantasy and not some art house flick or some historical epic. To be fair: you see it in Lord of the Rings fans who for years have been telling others who didn’t like the books that they just didn’t appreciate great literature. And before the films, you could see it among the literati who snubbed Lord of the Rings because it’s a popular fantasy rather than a dreary, post-modern, self-referential, obscurantist yawn. You see it in opera buffs who assume the rest of us are subintelligent because we don’t share their passion for opera. You see it in young rebels who look down on the lives of the conformist “sheeple” and who demonstrate that they are individuals and not “sheeple” — by all dressing and talking and acting and piercing alike. And you even see it in gourmets who extol the virtues of French food over more pedestrian fare like food from McDonald’s.

But the truth is: they’re wrong, every single one of them. They proceed from two clearly false assumptions: that there is one clear, objective, inarguable standard of quality; and that of all human beings, they somehow have been born with/been granted/achieved the unique ability to pronounce what the standard is.

But the fact is just the opposite. If I can avoid butchering the Latin too poorly, de gustibus non disputandum: with taste there can be no dispute. Or in the modern vernacular: there’s no accounting for taste. When someone tries to tell you that his tastes are objectively correct, he’s demonstrating how self-centered he is or how shallow his thinking is.

Does that mean there are no things that are objectively better than some other things? Can’t we all agree that Shakespeare is better than “The Simpsons”? Nope: I could gather up quite a debate on both sides of that issue; and the pro-Simpsons side would be every bit as educated and erudite as the pro-Shakespeare side.

Can’t we all agree that French food is better than McDonald’s? No, for multiple reasons: many people dislike new tastes, and prefer comfort and familiarity; not everyone likes the spices in French food; and if you grew up with French food every day, you might see it as “normal” and McDonald’s as a new experience, where novelty makes it attractive.

And so on, and so on, and so on. If you take any “objective” measure of general quality (as opposed to quality for a particular purpose, which may be assessed much more precisely) and examine it all the way down to its roots, you find personal tastes, past experiences, biases, and other responses that aren’t objective at all. There’s no objective measure of quality.

Except one. See, like many things that are immeasurable in the small, quality is measurable in the large, through statistics. No one person can absolutely proclaim that a certain thing is a quality product; but we can measure with reasonable precision how many people accept and endorse the quality of a product, by virtue of their purchases. In other words, the list writer I paraphrased has it exactly wrong: the closest thing we have to an objective measure of quality is popularity. If a significant number of people enjoy a product, then the odds that you will like it are higher. We’re all individuals, not ruled by statistics; but statistics are a useful piece of information to help you find products to try. Quantity purchased is a valid measure of quality. The market identifies products that the largest number of people accept as quality products.

And before anyone chimes in about betamax, QWERTY keyboards, CDs vs. albums, Microsoft, or any other oft-cited “evidence” that the market can produce the “wrong” answer: go reread my post, because you still missed the point. Don’t force me to go haul out the evidence that shows the conventional wisdom is wrong in every one of these cases, or I’ll produce so much it crashes the server.

Concern vs. Worry vs. Obliviousness




“Has this happened yet?” “Oh, no, what if this happens?” “This could never happen.”
“How likely is this to happen?” “Oh, no, what if this happens?” “This could never happen.”
“How can we tell if this happens?” “Oh, no, what if this happens?” “See no evil, hear no evil, speak no evil…”
“Can we prevent this from happening?” “Oh, no, what if this happens?” “This could never happen.”
“What will be the impact if this happens?” “Oh, no, what if this happens?” “No problem…”
“Can we prepare for that impact?” “Oh, no, what if this happens?” “Cross that bridge when we come to it.”
“Can we manage that impact if it happens?” “Oh, no, what if this happens?” “Cross that bridge when we come to it.”
“Who will be responsible for watching and managing this?” “Oh, no, who will we blame if this happens?” “I didn’t do it!”
“We’d better do something about this!” “Somebody’d better do something about this!” “This could never happen.”
“There’s nothing to do about this right now, so let’s focus on what we can do.” “Oh, no, what if this happens?” “Looks like smooooooth sailing ahead.”

Which column describes your project management techniques?

Disclaimer: This has nothing to do with any of my current projects or clients. The person who inspired this already knows who he is, and is firmly in column 1. Any other resemblance to actual persons or events is purely coincidental.