Software for the finest computer – The Mind


Posted by Tim Bryce on September 28, 2015


– It’s really not difficult as long as we use a little common sense.

To use this segment in a Radio broadcast or Podcast, send TIM a request.

In a recent Information Technology discussion group I am involved with, someone posed the question, “What is complexity?” I was surprised by the question as I thought it was understood what complexity was all about. Evidently not. The person posing the question was primarily concerned with complexity in system design, but I think it goes beyond systems, to all facets of business, be it related to products or services.

Complexity deals with the number of variables a human can successfully juggle at one time. Each of us possess an intellectual capacity to multitask, but there are mental limitations for all of us. It is like a juggler who takes on one too many balls which forces him to drop the lot. Some people can juggle more objects than others, but we all have limitations.

There are three variables in juggling complexity:

1. The volume of components in a product or service. For example, the number of parts in a product, the number of information resources in a system or program, or the number of customers to serve, employees, or vendors. For example, in an information system there are approximately 2,000 components to manage, and approximately 100 in a single program, which is still significant.

2. The characteristics of each component has to be defined. For example, height, length, width, weight, color, etc. Different components, different types of characteristics, e.g.; how we define the characteristics of a girder of steel is different than the characteristics of an employee, or a data element.

3. The number of relationships to other components. For example, how a wheel is related to an axle, how a worker is used on various projects, or how the data element, “Customer Number,” relates to records, files, programs and other system components. The problem is compounded when parts are standardized for use in multiple products, as General Motors did years ago in standardizing engine parts across their product line.

Based on these three variables, the human being must manage hundreds, if not thousands of variables in a work assignment. In an average information system design, there are approximately 50,000 variables to manage, and for a single program, there are about 2,000 variables. Workers are selected for assignment, in part, based on the number of variables they can juggle at one time.

The next obvious question becomes how to manage all of these variables. If we’re lucky, a person will use a reliable method of documentation to record them, such as blueprints in architecture and engineering, ledgers in accounting, or a “bill of materials” for a product. A bill of materials is a schematic depicting the parts in a product, how they relate to each other, and the characteristics of each component. Anyone who has a product warranty book for home appliances or major garden tools can find such a schematic, it is a common and effective technique for managing complexity. This concept is so effective, it was used as the basis for developing the data dictionary and Data Base Management System (DBMS) as used in application development work. However, the discipline to share and reuse components in the systems world, as logical as it may sound, is still the exception as opposed to the rule. Consequently, it is common to find considerable redundancy in system and data components, e.g; data elements, records, files, programs, business processes, etc. Consider this, it is highly likely there are multiple interpretations of “Customer Number” in a single company, as is “Product Number,” “Part Number,” the calculation of “Total Sales,” etc. Such redundancy complicates system integration thereby adding to the complexity problem.

The final problem is assembling the right parts to form the right products. This explains the rationale for such things as assembly lines and methodologies which define “Who” is to do “What,” “When,” “Where,” “Why” and “How” (the 5W’s + H). Such assembly lines/methodologies are devised by Industrial Engineers who are charged with assembling products in the most expeditious way possible.

There is actually nothing magical in managing complexity. It is just a matter of admitting our limitations and embracing a standard approach for documenting components, their characteristics, and interrelationships. The biggest danger is when we try to manage all of the variables in our head which, unfortunately, is how many programmers work today. Unfortunately, this results in considerable redundancy, lack of system integration, thereby complicating complexity further. All that is needed is little common sense, a standardized approach to documenting components, and some discipline to make it all happen.

Related articles of interest:

Managing Design Complexity – Feb 7, 2005
Communication Complexity – Sep 07, 2010
The Five Elements of Mass Production – Feb 11, 2013

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at

For Tim’s columns, see:

Like the article? TELL A FRIEND.

Copyright © 2015 by Tim Bryce. All rights reserved.

NEXT UP:  THE DISPARITY BETWEEN CAPITALISM AND SOCIALISM – Do young people know the difference between the two?

LAST TIME:  OUR PERMANENT RECORD  – You can run, but you cannot hide from it.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; and KIT-AM 1280 in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific). Or tune-in to Tim’s channel on YouTube.



  1. Wayne Brown said

    From a “systems design” perspective, Tim–I think this piece covers the argument that you have made for a long time that a good programmer will spend an inordinate amount of time first understanding the intricacies of the business model before they take any steps to design the system software. That time is spent understanding the “complexities” of the model and how “consequence” is derived from “action” or the “wrong action”. This is the very reason that the Obamacare system cost so much money (that, and the fact that this crony contractor felt they were in a position to rip off the government). Unfortunately, I do not believe our schools teach the discipline from that perspective anymore–its all about simply understanding the process, going through the steps, and expecting the right outcome. Most of the time that outcome is “the customer is screwed!”. Good stuff. ~WB

    Liked by 1 person

  2. Tim Bryce said

    An L.H. of Chicago, Illinois wrote…

    I enjoyed this piece, Tim. How do you feel about “open” systems, as opposed to “closed” ones? Aren’t open systems (where there is an added degree of unknown/unknowable) inherently more complex? Doesn’t this require an added level of adaptability and responsiveness?

    Tim’s reply –
    Good point. Yes, open systems presents problems. Using the cloud for example, means you may never know where all your resources are located and if something changes (either on your side or the cloud), you will not be able to analyze the impact of the change. For example, we had a university client (using closed systems) whose bank wanted to change their account number from 12 to 16 digits. By studying their components, they realized it would be a costly change. Consequently, they were able to make an intelligent decision whereby they told the bank, No, they would only accept a 12 digit code (not unless the bank wanted to pay for the implementation of the change).




  4. […] “Managing Complexity” “The Right and Wrong of Design” “Methodology Design 101” “Medical Records Interoperability” “Process Templates” “44 Years of PRIDE” “Information Resource Myopia” “The Systems Industry” “The USDA’s System Snafu” “Understanding Business Process Design” […]


  5. antlerboy said

    Tim, from my point of view you are very precisely describing complicated technical problems. You’re welcome to use the label ‘complexity’ for this, and the dictionary is your friend here: complexity – kəmˈplɛksəti, noun: the state or quality of being intricate or complicated. “an issue of great complexity”

    …but as usually understood this is what complexity is contrasted against. You are describing a situations with many variables and possibly many interactions. True complexity emerges from the interactions between two or more elements and is more usually defined as generating results which cannot be (logically or practically) predicted from knowledge of the elements. Wikipedia isn’t bad here –


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: