Breaches of Trust, Protocol, and Security

(note: this is a continuation of a story that starts here)

The Risk of Being Right

Every once in a while, people decide something is right.

"Right" is a very dangerous idea; among the most dangerous we've encountered. "Wrong" is great - it's saved our butts more than a few times but "right", has not done us too many favors, historically-speaking.

The more right something is imagined to be, the more people will fight to retain it past its point of usefulness. A great example of this is the replacement of the phlogiston theory with the oxidation theory of combustion.

If we had a good track record of being right when we say something is right, maybe that would be okay. Actually, it would probably be a good thing.

We've shown we don't have that ability, though. We've also shown that positioning an idea as the truth has a more-or-less-inevitable and very costly battle associated with the uninstall process.

So what we're left with is trying to find a way to position fewer ideas as right.

The Telephone Game

There's a reason they make us play the telephone game in kindergarten. I'd like to think it's more than just that it's an interesting effect you can demonstrate in a small classroom.

I think that, on some level, it's an attempt to demonstrate one of the most fundamental problems faced by mankind, today. Maybe not consciously by the teachers, but I suspect somewhere in its origins lies a motivation along those lines.

For those of you unfamiliar with the telephone game, the classic version goes like this:

1. The teacher arranges the children in the circle, with herself as part of the circle.
2. The teacher whispers something to one of the children next to her. It's usually something simple and factual, like "There's a bow in Jennifer's hair, today."
3. Each student whispers what they heard from the student next to them to the other adjacent student.
4. The message travels around the circle, changing hands once for each student until it reaches the teacher.
5. The teacher compares what the final message was with the initial version for the whole class.

Invariably, the message is mangled. Often, it is distorted beyond recognition. If you play the same game without whispering, the message keeps its original form, more or less.

The point of the game is to show that communicating via numerous intermediaries introduces error into the flow of information.

It rings true in business as well. Without a means of combating communication-error, you can be more or less certain that someone won't get what they want if they are asking someone to ask someone to ask someone for it.

The Atomic Asymptote

If you're not willing to completely throw away a piece of work the moment something goes wrong, it's too big.

The bigger the slice of work, the more deeply you are invested. The more deeply you are invested, the less willing you will be to abandon work. The less willing you are to abandon work, the more that work must be "right" up front. The more you have to be right up front, the more timid you will be in selecting your changes. Since you so carefully pick your changes, you'll want to make sure they are big enough to be "worth the effort".

It's a vicious cycle that destroys any sense of safety and, consequently, and kind of speed.

There's no real harm in cutting past the point where you'd be willing to throw everything out when it goes wrong. It just means you'll throw out less when you find something did go wrong. In fact (you'll be surprised to discover on your own), you'll make fewer mistakes and have to discard fewer changes in the first place.

If you're looking for the right size of an increment of work, try "atomic". That is, try a slice of work that is so small it cannot possibly be divided into two smaller, complete efforts.

Failing that, get as close as you can by continuing to ask yourself this question:

How can I do less of this, now, and the rest of it, later?

For Any Pattern: Check to See if It Creates a More Needs-Oriented Interface

Design patterns thinking tells us to design to interfaces. This has nothing to do with the keyword interface that is available in a lot of languages. It's about the English word "interface".

You know... the "I" in "GUI" or "API".

With few exceptions, a needs-oriented interface represents a better contract for a class than a capabilities-oriented interface would. The better-ness of this contract manifests in two ways:

1. The coupling that forms will likely be long-lived and resilient to implementation-changes.
2. It provides more context and drives better internal design decisions.

If you are considering whether or not a design pattern applies, try asking yourself if introducing the pattern will make the interfaces involved more about what should be accomplished or more about what should be done.

If the interfaces become more about what should be accomplished, that's a vote in favor.

If the interfaces trend toward a more imperative nature, you might want to reconsider.

Needs- and Capabilities-Oriented Interfaces

Among the many and varied ways to categorize interfaces is this one: needs-oriented and capabilities-oriented interfaces.

A needs-oriented interface is one that allows a client to ask for what they want. A real-world example of a needs-oriented interface is the mobile app for Lyft or Uber. You tell it where you want to go, negotiate and agree to terms such as cost and wait-time, and go there.

A capabilities-oriented interface is on that allows a client to ask for work to be done on its behalf. A real-world example of a capabilities-oriented interface a classic offset-barrel smoker. You control how much fire you have but adding wood, adjusting intake and exhaust vents, and leaving doors/hoods open or closed.

It's not that one is good and one is bad. They just serve different purposes.

An offset barrel smoker is part of an American tradition. There's an enormous amount of inertia around how it works. It's also very versatile. There are a lot of things you can do with an offset barrel smoker. Basically, an offset barrel smoker is part of the American Barbecue framework - it can be used in a lot of ways and it is okay - even expected - that it will not change.

Consider your programming language of choice. Can you think of a type that meets those requirements? It seems like the built-in collection types usually fit the bill.

Capabilities-oriented interfaces are really good for frameworks but they fall down when the fundamental assumption of a framework - mostly slow, primarily additive change - is violated.

Needs-oriented interfaces tend to withstand change a lot more readily. This is because a need doesn't usually transform into another need. It happens, but not often. Typically, a need either stays the same or goes away entirely.

Implementation details, on the other hand, can change on a daily basis.

What if the ride-sharing interfaces were focused on how you would arrange a ride rather than getting you where you want to go?

The moment something about fulfilling your need changed, the ride-sharing apps would have to change the interface to which you were coupled. If they brokered a sequence of text messages between you and potential drivers and suddenly text messaging was out of vogue, they'd have to change the interface and retrain a bunch of customers. If they get better technology, like driverless cars or single-passenger drones, they'd have to change the interface again.

Yet, by allowing you to express your need, the ride-sharing applications let themselves free to experiment with different processes and different means of conveyance.

The strength of a needs-oriented interface is that it will probably not change unless the associated need changes, which is rare. The weakness is that cannot typically be used by a wide audience in a large variety of ways.

If you are working on the .NET Core team or contributing to a broad-audience, low-level open source library, a capabilities-oriented interface might be the right choice. Otherwise, you probably want to focus on the needs being fulfilled when crafting a class, service, or application interface.

Developer vs. Bomb Squad