Formal v Informal Structure

In groups of people, there exist formal structure and informal structure. Formal structures are documented and consciously decided upon. They’re visible and accessible to everyone in the group. Informal structures form spontaneously, as people form connections and friendships, and information is transferred through conversation. Not every group has a formal structure, while informal structure is inevitable.

There are benefits to each kind of structure. Formal structure is defined, so people who are new to the group can learn where to go to get things done. Formal structure is possibly reproducible. Most importantly, formal structure scales. On the other hand, informal structure is efficient. Communication happens spontaneously. There’s no overhead.  If you’re part of the network, that informal structure works for you. If you’re not in on those conversations, you miss out.

Because informal structure forms naturally and organically, it appears in our code, too. Informal structure takes the form of coupling between implementations of modules, because they know too much about each other. When you use one-letter variable names, or mutable state that makes sense to you but isn’t fully documented, or fields named for historical rather than current purposes, then informal structure is happening. This can work on a small, stable team. It doesn’t scale, and it presents barriers to new team members. If you’re a consultant and you want your customer to be stuck paying you forever to maintain the same system, then informal structure is for you. If we prefer to move on to solve new problems, then we must fight our brain’s intrinsic tendency to rely on informal structure.

In code, formal structure comes from careful design. From structured programming to abstract data types to message passing in OO to functional purity,  good design practices all work to impose formal structure on code. Dependency Inversion Principle says “the implementation and user of the library must interact only through this abstraction.” Interface Segregation Principle says “I will know as little about you as possible, so I can’t interact with other parts.” Single Responsibility Principle says, “My job is to find the supplier with the best prices, so I do not know how to play golf with vendors.”

Informal structure is great among an agile team, which is sized and cultured to make sure knowledge is shared with every member. It’s efficient. It lets us treat each other as whole persons, which helps us be fully present at work. It’s the way our brains work best.

Our code does not benefit from informal structure, especially at any scale bigger than a screenful. We diligently apply design principles and coding standards to impose formal structure on our code, so that our software can grow and scale and be useful long after we have moved on. Fortunately for us, that class that approves travel reports doesn’t mind if we forget to say “Happy Mother’s Day.”


The inevitability of informal structure: