Showing posts with label modularity. Show all posts
Showing posts with label modularity. Show all posts

Tuesday, October 23, 2007

Principles of the Greatest Companies

What makes a company truly great?

The research by Jim Collins presented in his book Good to Great [1] from 2000 gives me a lot of inspiration. Collins researched the stock market and found the companies that had beat their market segment by 7 to 15 times over a 15 year period. The team then found the common qualities the great companies shared. Some of the results were really surprising. Interestingly, the list did not include companies like GE, Coca Cola and Microsoft. These did not qualify.

Below are the qualities :

1. Level five leadership
2. First Who, Then What. Pick the right leadership team
3. Confront the brutal facts - Murphy's Law
4. Hedgehog Concept (Strategy)
5. Discipline in culture
6. Use technology to accelerate

See [2] for a thorough walk through of the complete set of ideas that were introduced in the book. The book is also a very good read.

[1] Good to Great - cool study of the greatest business transformations.
[2] Jim Collins' web site

Sunday, October 21, 2007

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.