More complicated rules can allow for simpler messaging. The obvious application of this is probably data compression protocols. By applying the “complicated” gzip rules, we can simplify and shorten the messages we send between an HTTP server and client, for example.

But does this concept apply to teams?

I think it does.

There’s a lot of literature out there, some dating back at least a couple of decades, that talks about the benefits of pair or mob-programming (or collectively: ensemble programming); the practice of two or more developers sharing a single development environment, and talking through their work together.

The benefits of these approaches are many, and I’m not trying to diminish them in any way. But I am interested in looking at this through the “information theory” lense.

Ensemble programming is a form of high-context communication, with few rules.

At the far other end of the spectrum, we have completely async companies, perhaps like GitLab. For these companies to succeed, they must have many rules (and GitLab is not at all shy talking about the “rules” they’ve found that help them succeed in this way). But the benefit is that their communication may be much lower-context (i.e. “simpler”).

Now I’m not here to claim that either is better or worse than the other. I just want to call out the trade-offs that are being made when we choose one form of work over another.

How does your team work? Is it closer to the few-rules/high-context, or the many-rules/low-context end of the spectrum? What are the pros and cons you see of your approach? I’d love to hear from you!