Why nerds hate analogies

Nerds hate analogies. I know this because I hate analogies. I know this because I nitpick analogies. Well, I used to.

I’m not using the word nerd pejoratively here. I’m using it as a sort of shorthand for sciency techy people who like facts and logic. So basically… me.

But why? Why do nerds hate analogies? I’ve thought about this for a while and I think I’ve got a bit of a handle on it. Then again I might be full of crap. So don’t listen too closely.

I think this all has to do with arguments.

What Is An Argument

This is a terrible place to start. Sorry for that. But I’m not actually asking what an argument is. That’s pretty obvious, like asking what a star is. An argument is when you have two people with different points of view talking. That’s it.

What happens after that isn’t at all obvious. Because we can all agree what arguments are but we can’t seem to figure out what arguments are for. Like… why do we have them?

For some people, this is like asking what stars are for. They just are! It’s all very obvious.

But as with everything, it’s not so obvious at all. There are at least two things to consider. One is what we say arguments are for. This is easy to figure out. Just ask anyone. You’ll get ten different answers, and different kinds of arguments have different timbres, but they’ll all tend to cluster around facts and logic and trying to get someone else to understand your (obviously correct) view. Leaving aside that other kind of argument, which is actually just a fight and a different beast altogether.

We talk about arguments like they’re debates. And that’s not a terrible way to think about the way we think about them. In an ideal world, two people with different points of view get to present their point of view, and then at the end we all sit down and agree who has the stronger argument. The loser submits, the winner comes out victorious, and facts and logic win the day.

Now if you read that and said “but that never happens!” to yourself, you’re absolutely right.

Because that’s not what arguments are at all. I know this. I’ve rarely, if ever, seen an argument that works like that.

Maybe I’m just hanging out with the wrong people. I don’t think I am. I think most, if not all people work this way. We say that arguments are about facts and logic and strengths of positions, and making good points, and having discussions that lead to agreement… Yet every argument I’ve seen leads to all the participants slinking away to find better arguments, not better positions.

People are slippery that way.

What Are Arguments For

Arguments actually function as a defense mechanism for things you’ve already decided. If you think there’s any semblance of some kind of scientific method in arguments (and a lot of the time in science, but that’s another matter altogether), you’re either a very special snowflake or a very deluded snowflake. I mean, you must know that your response to feeling like you’ve lost an argument, especially one you care deeply about, isn’t to throw your position out the window, but to figure out a better way to justify your existing beliefs.

Arguments are actually kind of traumatic. Someone has come along and is trying to mess up the internal consistency of your thought. Somewhere deep inside you know that your already have a crazy shortage of consistency, so your brain just needs to defend, defend, defend, until you can no longer defend. Then you take a shower the next morning and you have a bolt of insight!… that magically happens to bolster your position.

A Brief Word On Logic

Before I go any further down this path I want to talk about logic for a second.

Logic is a tool. So are a lot people who talk about it a lot. (Excepting people actually studying logic, but that’s a whole other thing.)

It’s a tool that can prove nonsense. Logic takes inputs and produces outputs. The problem is the age old problem of garbage in, garbage out. So let’s say you’re using logic and you feed it a bunch of false premises. You get a result that doesn’t make any sense.

That’s the problem with logic, right?

Well, no, not really. Because most of the people who use “logic” are actually using the word logic and not actual using logic.

I remember reading a book by Alvin Plantinga that had a lot of formal logic in it. I couldn’t make much sense of it because I’m very much not Alvin Plantinga. But the point remains, we just don’t use formal logic. Or really even informal logic.

Or really logic at all. We say “logic” but we mean “this makes sense to me”.

The really annoying result of this is people who use logical fallacies as counter-arguments. Straw man! Appeal to authority! Appeal to the stone! Ad hominem!

Here we have a bunch of yammering ninnies who know enough to critique the informal logic of a statement without actually examining its soundness. Remember, just because some argument has a logical fallacy doesn’t mean it’s not true! (You could almost say that an argument from logical fallacy is… a logical fallacy. But then the snake begins to eat its own tail and universe is divided by zero or something.) That you can analyze a statement by scrolling through a Wikipedia page doesn’t prove or disprove anything.

Okay, so it maybe proves that you’re a jackass. But that’s beside the point.

A Brief Word On A Brief Word On Logic

So why am I talking about logic, other than to gripe about some internet knownothings?

It’s because it’s important to what I’m about to say. I don’t know how to express this well, so I’ll tell you a story.

I knew a guy who was very concerned about facts and logic. He was always talking about is this logical, is that logical. He would take really defined stances on things based on logic (which wasn’t actual logic mind you, just whether or not he could make something make sense to himself). He wasn’t doing anything wrong, not at all. I was really impressed with the amount of thought he put into doing thing that other people just did.

He didn’t like to speed on the highway. Because the speed limit was a law, just like not setting fire to a nunnery was a law, and if we sped on the highway, didn’t that mean that we were also implicitly approving of burning down that nunnery? (There’s a deeper law about speeding on the highway called “not putting your family in danger by obstructing the flow of traffic”, but I didn’t come to that idea until later.) For a while I was very impressed with this argument, except that I kept speeding anyways.

I was impressed but not persuaded. I might have agreed, intellectually, about this kind of absolutist framework of viewing the law as a monolithic entity where speeding and murder were on the same level. But it didn’t change my behaviour. I actually wondered about that a few times. I didn’t realise at the time that I actually didn’t agree. I just couldn’t put into words my objections, which weren’t logical and rational and didn’t have the hollow ring of facts about them, but were actually simply that some laws are law-eyer than others, and that morality isn’t decided by a penal code.

Persuasion is important. Think of all the things you’ve been persuaded to do for love. You may have even converted to a religion for love (and meant it!). Look at all the people who suddenly become devout Christians or Jews or what have you, exactly when it’s conveniently required. Love has this way of making up your mind for you. There’s all kind of stuff that suddenly clicks into place. You become a different person, or at least a different kind of person.

Love kind of short circuits the bits of your brain that want to grasp the facade of logic.

And so do analogies.

An Analogy From Analogies

If you’re a good nerd, you probably hate the meandering train of reasoning I used to get here. I made a few analogies, talked about logic, told a story, then made another analogy. That’s okay!

I did it all on purpose.

Sorry.

The point I’m trying to make is that logic is a domain-specific thing that has certain uses. Arguments are domain-specific things that have certain uses. They are technically meant to do one thing but are press-ganged into doing another, more pernicious thing, which is defense of pre-existing positions.

Analogies are different.

They’re not about facts. They’re about state transfer. By using an analogy, you’re trying to express to someone else your state of mind. You’re making a comparison that is meant to explain to someone why you feel a certain way without using tools like logic and arguments.

It feels a bit like cheating.

There’s a long oral tradition of using extended analogues (aka parables) to help people understand something. You may not like this. If you’re a super-nerd you’ll probably say something like Well, that’s because human minds are silly things that evolved to take stories more seriously than logic and facts. Because after all, the end goal of humanity should be to become correct-thinking computers, right? All this mushy meat instead of the glorious computational accuracy of silicon! What a shame.

That may be. But the reality remains that we are human, and we do respond to stories and analogies and anecdotes far better than we do to lists of facts.

Like, it’s safer to send your kids to the park down the street than it is to let them play in your backyard… if you have a pool. But we don’t fear the pool because we know the pool. We fear the child-snatcher because that narrative has potency.

Analogies are essentially stories, right? And they function in the same way stories do. They provide a slight narrative, they give a small insight into how you think.

Analogies are tools of persuasion. They’re not tools of argument and defense. They can be used that way and maybe even often are, but they’re particularly hard to “defend” against.

But we’re going to try anyways!

Pay No Attention To The Analogy Behind The Curtain

There’s no good way to respond to an analogy without responding in kind. A better analogy. But then you get trapped in an analogy loop where everyone is agreeing to disagree because we all kind of understand where each other is coming from. And we can’t have that.

So the standard nerd turns to the standard nerd toolbox to defeat the analogy…

Logic will save the day!

If analogies short-circuit the logic/argument paradigm, there’s only one way to get back on the offence. Pick apart the analogy. It’s not exact enough! The analogy breaks down! It’s not good! Make a better analogy!

This is all standard stuff. But you have to understand that it’s a distraction the same way presenting a logic fallacy is a distraction. It’s not really salient. We all know analogies are inexact and break down somewhere. If they didn’t break down they’d just be exact descriptions of the argument at hand and would lose their usefulness. Which, come to think of it, if you’re of that sort of disposition, is exactly what you want.

So you nitpick the analogy until it breaks down, wash your hands, and pretend it’s been a good day’s work. The analogy has been short-circuited, and we’re back to logic/argument land, where the free-flowing dialogue can go on forever with no one ever having to adopt a different (read: unsettling, new) opinion.

Persuasion

My point is that analogies are tools of persuasion.

Arguments are not.

Analogies are state transfers.

Arguments are not.

Analogies can be effective.

Argument are almost always not.

Analogies aren’t the only tool of persuasion. It’s just one of many. It might not even be a very good one. But my point is a little bit more meta than simply facts vs analogies. Arguments are not effective in drawing people together. They don’t naturally help people (especially on the internet) understand each others state of mind better. It naturally creates an us vs them mentality, and an isn’t an us vs them mentality the root of all violence? The cavemen who wear pelts of deer who must kill the cavemen who wear pelts of the unclean animal.

And yet we argue. All. The. Time.

I’m not sure what that says about us humans.

Development vs Production

When I think of development vs production I’m thinking of manufacturing specifically. These terms mean slightly different things in, say, software, where development is where you make the thing stable enough to run and production is where you run it.

On the other hand maybe that’s not so different after all. Development makes it run, production runs it.

But that’s all very obvious. I want to think about product development and production in more conceptual terms, thinking about how each area does what it does. And I want this to be a little abstract. So I’m going to talk about development and realization instead of “production”. (Just to prevent any confusion here, I’m using the term a little differently than the ISO 9001 spec does, where design, development, and production are all subsets of realization.)

First, product development and realization are two separate things. This isn’t obvious to some people. You know who these people are. I once heard a developer friend of mine years ago (he worked at a bank, which in kind of super-scary) describe his co-worker as a “cowboy”. The sort of person who doesn’t value (or worse, understand) the difference between development and production, who pushes changes from development to production with minimal or no check (or worse, develops in production).

This was software, but manufacturing has the same sort of thing. In a system like ISO 9001:2008 development and realization are considered two different domains, each with their own sets of paperwork, processes, work instructions, and potentially different management teams.

In a large company you might have development plants or skunkworks. This makes the separation super obvious. And obvious for a reason, you don’t just push development changed into a realization scenario where you can make 10 million widgets wrong.

In a small company the domains get a little muddier. This is why a conceptual framework is useful. The same people might be managing the development, producing prototypes, doing testing, as are managing the production lines, running the production lines, and doing inspections.

There might not be a clear reason to separate development from realization (at least at first), especially as a 1-person or few-person outfit. When you’re a small company, you’re probably not making 10 million widgets where development is a much smaller part of your overall cost structure. If you’re developing a lot of one-offs and specialty products, maybe most of your time can be taken up with development.

This is why a development/realization conceptual framework is important. It helps separate domains, and by doing so helps you to stop making the same mistakes over and over again.

First, product development and product realization have different inputs. An input, of course, is just something you dump into a process in order to do some work on it and get something out the other side. This can be materials, specification, people, processes, etc. (And usually realization has as one of its inputs the results od

They also have different causes and effects. Things that go wrong in development often are (but don’t have to be) very different from things that go wrong in realization.

Even more abstractly, they have different purposes. So let’s start there.

Different Purposes

Realization exists to make a product, to bring it to market in a certain form. It might seem at first that development also exists to make a product (as prototype), but that’s not exactly true. Or, if you’re doing in that way, you’re potentially doing development wrong.

Development actually exists to make knowledge. Specifically, reusable knowledge.

Why would you develop, let’s say, “a tool that doesn’t vibrate while cutting Titanium”? That’s a narrow goal. It’s applicable to just one thing. A more abstract and useful expression of this development process would be “a type of geometry that doesn’t vibrate in a material with certain properties”.

Then you can take that knowledge and reuse it for different items of that class. I think of this as a sort of don’t repeat yourself (or DRY) for product development.

Instead of ending up with a tool, you end up with a set of criteria than can be applied to tool, plural. And instead of that knowledge accumulating in one person’s head, it accumulates as a set of specifications.

I’ve seen this so very many times. Someone says “My customer wants a tool that does x and y”, a single person does the development and realization process at the same time, no specification is written, the tool goes out, and the knowledge is nowhere to be found. This makes for a very valuable person but a useless procedure.

(This doesn’t even touch on the amount of waste generated by this kind of process conflation; think of all the extra time spend developing the same tool again and again, reinventing the wheel, only to have the product returned because something went wrong somewhere in this crazy whirlpool of a development process. It might seem like time has been saved in the short term, but as with most things, it’s a long-term disaster.)

Different Causes and Effect

When you do development and realization at the same time, you risk conflating cause and effects, which are different in each domain.

Typically in development, causes of failures are related to development type things (experimentation going wrong as it always does, etc). Since you’re developing a specification and creating knowlege, you’re venturing into the unknown where unknown things can happen.

In realization, causes of failures are usually related to process type things. The processes should be nailed down enough that when something goes wrong (apart from the usual acts of God) you can track down where the process hasn’t been followed or where the process needs to be changed.

These causes and effect, when taken together, when development and realization are bundled, become exponentially more tricky. Suddenly your production causes and effects are no longer bounded by adherence to processes, instead you have to look at your processes and your development criteria, and so on. Suddenly your troubleshooting tree has way, way more branches. It can become so complex that you just can’t troubleshoot at all, and you just ship and pray.

I don’t think I need to say why guess & test plus ship & pray is a terrible, terrible idea.

Different Inputs

My final thought is that development and realization have different inputs. In fact, one of the inputs of realization is a specification from development.

Development takes existing knowledge, engineering expertise, and customer specifications, and outputs a specification. This can be an prolonged period of prototyping and testing, but if you’re doing similar things quite often it can be simply spitting out a specification with small modifications. (Eg, my customer wants this thing that we already make, just with a different dimension or material.) In fact, with the proper ongoing research and development efforts, even a small company can radically shorten development engineering lead times with reusable knowledge.

Not only that, but reusable knowledge doesn’t have to be domain-specific. For instance if you’re improving one process, it’s quite possible you can reuse that improvement in many processes. The knowledge generated by development can be diffused across both development and realization. This is the kind of thing that can save serious cash by improving processes across the board and shortening lead times.

Realization on the other hand takes as one of its inputs (possibly one of many) the specification produced by development. With proper modularization it may even be possible to create a series of specifications that can be mixed and matched to achieve different results as required.

For instance where I work we could have a meta-specification that simply calls out other specifications and mixes in the customer’s special requirements.

Or if the customer needs something truly oddball, a new specification is created. (From my experience 90% of our custom work would easily be covered by a meta-specification.)

Different Inputs

Just to wrap things up, this is why I see development and realization as two different domains. They accept different inputs, they produce different outputs, they have different causes and effects, and they exist for different purposes.

I hope I’ve done a decent job of explaining why I see conflating the two domains as a really dangerous idea.

That said, I think a lot of companies, especially small outfits, don’t see the immediate benefit of decoupling development from production. Maybe this is because of cost concerns (I need to make a whole new division!) or because of lead time concerns (I have to do two things in line instead of at once!).

The problem is the value proposition here is kind of hard to quantify. If you’re worried about those things you’re probably also not doing proper analytics on scrap rates, production breakdowns, customer satisfaction, nonconforming product returns, and all the other fun stuff that comes along with doing too many things at the same time.

And there’s no way to really make this sexy. This is sort of the least sexy possible domain. There’s nothing really clever, there’s no Suits-esque maneuvering here.

All I can say is that decoupling development from production is a proven long-term success story. It’s going to be one of the ways you make your company (at least, if that’s what you want) into an organization instead of a random collection of people and things those people do. It’s going to result in fewer lost man-hour trying to reinvent a process or specification (again). It’s going to cut down on the amount of lost time and money on returns, replacing faulty tooling, dealing with upset customers, and scrapping out nonperformant parts.

The greatest benefit, though, is something really intangible. It’s peace of mind. You’re not relying on one guy who just “knows” things. You’re not guessing and testing. You’re not shipping and praying.

I don’t know about you, but peace of mind if kind of a big deal for me.