As I am between jobs now, I have time to catch up on some reading I’ve been putting off for some time now.

I am in the middle or reading “Simplicity & Complexity in Games of the Intellect” by Lawrence B. Slobodkin. Coincidently I’ve also been watching last night the 2009 movie “Duplicity” which made me ponder about some of the unnecessary twists and turns in the book. Notwithstanding the above, there are some good and valuable comments in the book about the essence of complexity.

The author makes the obvious observation that the spectrum between the simple and  the complex is filled, on one hand with objects and systems that serve some function or fulfil some role with a very small number of internally distinguishable states, parts or conditions; and on the other hand with complex objects and systems that cannot be reduced to simple ones.

Clearly the above is already a form of simplification, necessary to reduce the vastness of this topic into a printed medium. The author, implicitly, concedes that simplicity and complexity are somewhat meaningless terms as ultimately any system definition is based on some form or order of magnitude. Observations from the natural world can easily demonstrate that any seemingly simple object or system can be amalgamated up or broken down into almost infinite levels of abstraction, constrained only by our existing technology.

From a system engineering perspective it can be argued that the above is equally relevant. A system might comprise of only small number of components or interactions, but a closer look, perhaps from a programmer perspective, might reveal a complex set of business rules and logical functionality. If to take Lawrence B. Slobodkin’s perspective, the need to view a system as a simple or complex organism is very much in the eye of the beholder. It seems almost inevitable that various players in the system engineering domain need to use varying degrees of abstraction, as relevant to the roles they play. In some sense, when conceptualising the problem domain, simplification and abstractions are called for. When designing the system, a greater level of specification and detail are required, but although these imply increased complexity, breaking them up into smaller chunks can still result in manageable and digestible bits.

Ultimately, whether a system is complex or simple is a matter of subjective interpretation based largely on the availability of information and the degree to which this information has been substantiated by past experience or supporting models.

Having gone through this book has given me a different appreciation of what complexity is all about, realising the perhaps the path for reducing complexity (or the appreciation of what might be constituted as complexity) is through increased knowledge and understanding of the relevant domain.

I will most certainly think about it!

Print Friendly

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

No Comments

  1. Pingback: Shim Marom

  2. Pingback: Mike Clayton

  3. Pingback: Shim Marom

  4. Pingback: Shim Marom

  5. Pingback: Shim Marom

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: