As a new coder, one of the biggest challenges I’ve faced is consistently obeying the Law of Demeter. For those of you unfamiliar with it, the Law of Demeter is a programming guide which stipulates:
Each unit of code should have only limited knowledge about other units: It may only units explicitly related to the current unit.
For a real life example, imagine you’re the pizza guy. When you go and deliver a pizza, you need to get paid. Do you go into your customer’s wallet and pluck out a few bucks?
No. Of course not. You ask the customer for payment, and they would go into their own wallet to pay you.
This is the Law of Demeter in action: you, as the pizza guy, only know about your customer - you have no knowledge of their wallet. So to get paid, you ask your customer to pay you and they go into their wallet and take out money to pay you.
Makes sense, right? The Law of Demeter is actually so widely adhered to that breaking it is a “code smell” - a signal that your code is less than optimal.
The Anti-Law of Demeter in Organizations
Before I started Musubi, I was a strategy consultant. One of the things we did was structural reorganization - essentially, how do we break down the organizational silos which affect nearly every large company. When individual departments contain thousands of employees, it’s very easy to become entirely inward facing.
In almost every case we worked on, the goal was to get departments working together better, faster, and more closely. Working in such a closely coupled environment meant that the company could bring out the best of its capabilities in each product.
Which is the exact opposite of what Demeter would stipulate.
Why does something that makes so much sense in a programming language work so poorly in a people based organizations?
Classes of Connections
The Law of Demeter works best in situations where the connections between objects are durable, well documented, and atomistic. If you’re the pizza guy, all you need to know is that you are going to get paid (durable expectation), that it’s going to be in cash or credit (well documented payment methods), and that your obligation is done once you’re paid (atomistic payment). As long as those three conditions hold, you don’t really care what the customer’s doing with his wallet.
On the other hand, the links in organizations are typically ad-hoc, personal, and interdependent. Developing a product requires many links between a number of different individuals which are constantly in flux, sending iterations back and forth. There’s no easy way to throw a clean, well defined interface on that.
Operating a company through interfaces can work. Car manufacturers now outsource the majority of the components in a vehicle, doing just a few critical components and assembly in-house. Dell made an empire by allowing for near total customization using standardized parts.
But would the MacBook Pro’s Retina display exist without Apple’s incredibly close interactions between its designers, engineers, and supply chain? How would Amazon’s Kindle fare if it was just another tablet, separate from the Amazon webstore? Would SpaceX’s Falcon 9 rocket reduce spaceflight costs by an order of magnitude if it outsourced its design?
Following the Law of Demeter is an organization smell. Use the Law of Demeter in your code, but not in your teams.
