When the Law of Demeter is applied to organizations

The Law of Demeter is a design guideline which can be summarized as the principle of assuming “least structural knowledge”. Wikipedia defines it with respect to object-oriented software as:

The Law of Demeter for functions requires that a method m of an object O may only invoke the methods of the following kinds of objects:

  1. O itself
  2. m’s parameters
  3. Any objects created/instantiated within m
  4. O’s direct component objects
  5. A global variable, accessible by O, in the scope of m

In particular, an object should avoid invoking methods of a member object returned by another method.

In a more general sense, it can be summarized this way:

  • Only talk to your immediate friends.
  • Do not assume anything about the internal structure of others.
  • Each unit should have only limited knowledge about other units.

The main goal of the law is to reduce errors due to wrong assumption regarding objects you do not really know about. You stick to stick to what you can control or things which are close to you.

Even in software, strictly sticking to the law of Demeter can sometimes lead to writing many small wrapper methods that do very little but delegate. It does improve encapsulation and decreases coupling but does result in wider interfaces.

When you transfer the law of Demeter to organizations, replacing objects by individuals or teams, you get something like this:

  • Focus on your tasks, the components you are responsible for.
  • When it comes to knowledge, focus on depth rather than width.
  • Use the information you’ve been given by the one triggering you but not more.
  • If someone tells you about an issue reported by someone else, keep talking to the middle man.

I guess it will sound similar for many readers.

The advantages of such an organization are:

  • You feel safe as you only work on things you know and can control.
  • If you get technical experts, you do not need to spend a lot of money on domain training.
  • If you have domain experts, you do not need to spend a lot of money on technical training.
  • Peace of mind: you leave them alone and they leave you alone.
  • You can have a fully distributed team, since dropping specifications over the fence is pretty much all you have to do.
  • As soon as you get instructions, you can directly start working without checking whether everything has been properly specified.
  • If something goes wrong, you can always blame it on the previous guy in the chain.
  • When a customer has a problem, he/she contacts the first level service team, which contacts the second level service team, …, which contacts the development team. So a developer who has no time to solve the problem just needs to request more information and will only be contacted again a few days.

Quite a long list of advantages… And what’s great is that you only have a few minor disadvantages:

  • Since the one at the end of the chain, knows nothing about the end customer, you’ll probably not build the right thing.
  • Information lost in translation.
  • You’ll only notice important missing pieces very late in development.
  • People keep blaming others and nobody feels responsible for anything.
  • You need months to solve service tickets which could actually be solved in days.

It doesn’t sound so bad, does it ? Especially, when you are not a customer or the owner of the company… Well, basically it’s great as long as you’re the one getting paid for this and not the one paying !

Important side note: If you’re offered stock options, just ask for cash instead, you do not want to become an owner of that company…

Leave a Reply

Your email address will not be published.