Being Orthogonal and DRY through McKinsey's MECE

Two of the important lessons that many software engineers have learned through experience is so brilliantly explained in the book Pragmatic Programmer:

• Orthogonality - "Things that are not related conceptually should not be related in the system."
• DRY (Don't Repeat Yourself) - "Every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation."

While skimming through the book The McKinsey Mind (a follow up of another very similar book called the McKinsey Way) I suddenly found the same principle being present in the Firm's analysis methodology. The principle is called MECE and stands for:

• (ME) Mutually Exclusive - "must ensure that a list of items is mutually exclusive, or that every item is separate and distinct"
  
• (CE) Collectively Exhaustive - "it must also be collectively exhaustive, that it includes every issue relevant to the problem"
  

According to the source, the MECE principle is used by the associates in the Firm to analyse different scenarios or to develop a list of questions concerning a particular issue. It is funny to see that the same principle is applied by both successful software designers and successful business analysts. The principles are just coined differently. DRY and orthogonality covers ME. You can say that CE is supported by any working software system in that it works.