Orthogonality is a choice

There are many definitions of orthogonality. For the overlapping worlds of design, engineering and business, we can summarize with this question: what needs to be solved together as one whole, and what can be solved separately? Two things are orthogonal if we can work on one of them without having to get into the details of the other.

Programmers know this. When you have to think about too many moving parts at once to make a change, you get overwhelmed. When you can change one thing with confidence that it won't break anything else, you make progress.

Designers know this too. Some changes are local and don't affect their surroundings, like swapping one image with another of equal proportions. Other changes cascade, breaking the layout and forcing you to find a new way to fit all the puzzle pieces together.

This is what "factoring" and "refactoring" are about in both fields: setting the boundaries where you can change one thing without affecting other things. Like the containers in a UI layout or the abstractions in the code.

These same questions about factoring and orthogonality also apply at the larger scale of product decisions and the design of the organization. At these larger scales they often go by terms like "bundling" and "integration." They concern which kinds of work need to be done together in the same project, in the same team, or within the same firm.

Business books like Clay Christensen's Innovator's Solution treat this well. See Chapter Six on Interdependent vs. Modular architectures. My favorite recent example is the Apple Pencil. Before the Pencil, tablet styluses were orthogonal to the device hardware. They assumed a capacitive touch screen and that's all. To make a stylus with meaningfully different capabilities, Apple integrated the design of the stylus (the Pencil) with new technology under the glass of the iPad. The stylus wasn't orthogonal to the hardware anymore, it was integrated. Both projects had to be designed and shipped together to achieve the jump in capability.

As Clay explains in the book, integrating is the path to higher performance. You can achieve more performance when you control more of the parts and how they fit together. But integration is also more expensive. In my mind — and I lump all this together under 'orthogonality' — that extra expense of integrating is different in scale but not in kind from the cognitive expense of a designer solving more puzzle pieces at once or a programmer holding more of the system in their head to make a change. Sometimes it's worth it, but often times it's not.

Usually, lack of orthogonality is a bad smell. It's the classic "ball of mud" that programmers talk about: those big chunks of code that do too many things in one place and are thus opaque.

Lots of project plans are bulls of mud. Another name for mud is "scope creep."

I'm working right now on a project pitch for Basecamp 4. It's a major rethinking of how we do email notifications. The problem is, there are dozens of things we want to make better under the banner of "email notifications." Which of them belong in THIS particular project?

For this concept, there are things we need to integrate to get the better performance: a different email template • sent at a different frequency • modifiable by a different setting • exposed in a new place • set to a different default than today. I tried to factor out as much as I could, and there's still this irreducible core of interdependent parts.

At the same time, the project could have easily become two, three or four times as big. That's because there are a lot of other changes that independently have value, and solve real problems, and would make customers happier, but they aren't irreducibly interdependent. They're orthogonal. They include changing what goes through our notification channels and how those things are bundled into one vs. separate notifications, for example.

As I was sketching different bundles for this feature, I wrote to myself "orthogonality is a choice!" in my Notability notes. It felt great to be able to point to a chunk of the project and say "this is valuable ... but it's orthogonal. We don't have to solve it in the same time and place as these other things." Pulling parts of the project apart into orthogonal pieces gave me, at the strategic level, the same feeling programmers and designers get at the implementation level: the feeling I could move faster, change less, and have more confidence that it was all going to work.