The three layers (i.e. science, engineering and art) for invention and innovation of each of the products.

The progress of pure science is discovering new truths (or irrefutable facts) for expanding the boundaries of human knowledge. The scientific research is nothing but pursuit of absolute truth. The scientific foundation comprises of irrefutable scientific facts/truths, and well tested/proven theories/concepts created by using sound reasoning, logic, which are further supported by empirical evidence (e.g. repeatable experiments). The scientists propose falsifiable hypotheses and each of the hypotheses is tested against whole world of known/recorded facts, observations to falsify the hypothesis. Any falsifiable theory/concept is not false, but it can be falsified, if it has flaw. Any hypothesis is eventually accepted as a proven theory or concept, when no flaw can be found.

The pure engineering is inventing (and/or innovating) useful things (e.g. parts, and engineering infrastructure such as tools, processes, models) by relying on the sound scientific foundation. The components such as internal combustion engine, Jet-engine, CPU, DRAM or parts for fiber optic networks are pure engineering inventions. Likewise, ingredient parts such as steel, plastic, gasoline, cement, battery-parts and metals or alloys) are pure engineering inventions. These kinds of things are continuously optimizer for sheer engineering perfection, performance and precision. So such things begin as pure engineering inventions and continuously evolved by mostly pure engineering innovations.

Even an ugly looking compact internal combustion engine looks beautify and gains admiration, if it is two times more fuel efficient at lower price. No one cares the looks of CPU, DRAM or parts for fiber optic networks, if they are 2-times better than nearest competition in tangible aspects such as price & performance. The research effort and process for inventing or innovating each of the engineering things must rely on a set of scientific facts or concepts, and the research effort would fail, if there are flaws in the scientific facts and concepts.

These kinds of engineering things are used to create products used by human beings (e.g. consumer products or products that are used by engineers). The architects and designers of such products employ engineering and art (e.g. to suite taste or preferences of target users) to innovate user friendly products (e.g. Cell-phones, PCs, TVs, iPod, Twitter, Whatsapp or Facebook etc.), by relying on the things invented and innovated by employing pure engineering (where the engineering progress was possible only due to relying on sound scientific foundation). Although only the art is visible and makes competitive deference in consumer products such as iPhone or Facebook, there is lot of invisible science and engineering goes into each of the products.

Steve Jobs and Mark Zuckerberg are Steven Spielberg’s of technology industry – Great story tellers - know what users or consumers want better than the consumers themselves. There could be dozens of companies who has engineering capability to build products such as iPhone or Facebook, but can’t deliver on artistic taste (or creativity) and understanding of consumer intuition (or fascination). They have great intuition, taste or charisma to capture our imagination/fantasy. All the other competing companies have access to same engineering and scientific knowledge, the inventors and innovators of consumer products succeed by heavily relying on intangible artistic taste and creativity for differentiating from competition. Even if they encounter few technological shortcomings to achieve envisioned perfection, I am sure most other competing companies could overcome the shortcomings (if confronted with the same technological shortcomings).

My objectives: (1) expanding boundaries of mankind's scientific knowledge by discovering unknown facts about the physical functional components and CBD for physical products, and doing engineering research (by leveraging the existing and newly discovered scientific facts) (2) to invent new useful things such as new kind of component models and processes, and (3) inventing basic missing pieces for software engineers such as CASE-tools & reusable libraries.

Each of the successful products used by mankind is blend of the three ingredients (i) scientific discoveries, (ii) engineering inventions and (iii) art (artistic imagination) or taste (tasteful design). In the layer-1 (scientific research), absolutely there is no room for subjectivity. In the layer-2 (scientific research), there may be room for small percent of subjectivity. The joy of pure engineering is creating best algorithms such as compression, clustering and encryption or decryption, which are tangible and can be measured against alternative inventions in key performance aspects. In the layer-3 (research for products such as tools and libraries for engineers) there is lot of room for intangible subjectivity and artistic creativity (e.g. each set of consumers might like a different version of the same product invention). There could be multiple winners, since there is a room for subjectivity.

Each of the successful products used by mankind is blend of the three ingredients (i) scientific discoveries, (ii) engineering inventions and (iii) art (artistic imagination) or taste (tasteful design). One must be clear in which layer (i.e. ingredient) one is focusing, when one is doing research. Likewise, one must be clear which layer is the contest, if one is discussing or debating. In the layer-1, goal is to discover the facts that are closer to absolute truth (e.g. compared to competition). One can invent (or innovate) better engineering things by relying on better facts. In layer-3, there is lot of room for subjectivity, so whoever predicts the user taste/needs (e.g. by fulfilling user imagination/fascinations) wins.

The inventions & innovations of engineering (i.e. layer-2) can be expanded by expanding the boundaries human knowledge in layer-1, for example, by discovering new scientific facts. The expansions of layer-2 allow expansion of layer-3, for example, resulting in inventions of new products and innovations in existing products. The scientific and engineering progress would certainly derails and end up in crisis, if there are errors in mankind’s knowledge in layer-1. That is, expanding the layer-1 leads to expanding layer-2 (invention of new things and drastic improvements to the performance of existing things), and expanding the layer-2 leads to expanding the layer-3 (i.e. invention of new kind of products and drastic improvements to existing products).

There are huge gaps in the layer-1 (i.e. in computer science) such as fundamental flaws in the basic axioms and concepts that are foundation for existing software engineering paradigm. The software engineering ended up in crisis because it has been evolving for nearly 5 decades by relying on such flawed concepts (by assuming them to be facts). These flaws are buried deeply under a thick layer of hundreds of books and thousands of research articles published world over spanning 50 years and made invisible by resulted distortion of reality and a complex paradoxical paradigm.

How could mankind invent computer chips by being clueless about the essential properties of electrons, such as how they behave in semi-conductor material? How could mankind invent fiber-optic networks by being clueless about essential properties of light, such as how it behaves in strands of optical-fibers? Likewise, mankind can’t invent real CBD for software by being clueless about essential properties of physical components and essential aspects of real CBD for the physical products, since the essential properties enable the components to achieve the real CBD having the essential aspects (e.g. 0% spaghetti code).

The order of product creation is (i) discovering the scientific reality and facts, (ii) use the knowledge of the facts and reality to make engineering inventions, and (iii) The products are created by using the engineering knowledge and expertise. But computer science defined the nature of components (and aspects of CBD for software) without any basis in reality (or fact), and researchers of software engineering have been trying to invent CBD for software for nearly half-a-decade by relying on erroneous scientific foundation. Trying to invent engineering before science is like putting cart before horse - it never works. This passionate effort of thousands of researchers spanning over 50 years resulted in evolution of a complex paradoxical paradigm. This is no different from trying to advance the scientific knowledge for 1000 years, by relying on the erroneous fact that the Earth is static at the center, which resulted in evolution of a paradoxical paradigm that was so complex that even saying the truth “the Sun is at the center” 500 years ago offended the common sense and insulted the deeply entrenched conventional wisdom (of then prevailing geocentric paradigm).

My request is just discover the scientific truths (E.g. essential aspects of real CBD of physical products and the essential properties of physical functional components that are enabling them to achieve the real CBD of physical products). Then rely on the scientific foundation (of truths) to invent equivalent real software components for achieving real CBSD (CBD for Software) having the essential aspects. Each of the definitions for each of the kinds of software components known today has no basis in reality, so it is a huge violation of scientific process to blindly rely on such software components for inventing CBSD.

Is it possible to discover innate nature and essential characteristics uniquely and universally shared by all the physical functional components?

Dear Friends,

I believe the answer to above question is Yes! If researchers of computer science try to discover the innate nature and essential characteristics uniquely and universally shared by each and every known physical functional component, I can’t find any valid reason why the researchers could fail. The last several paragraphs are dedicated to support this answer (please let me know, if there is any flaw).

If the answer is Yes, why is it not possible to invent equivalent software components sharing the innate nature and the essential characteristics?

Let me define what is meant by essential characteristics: The essential characteristics are the minimum set of properties uniquely and universally shared by each and every known physical functional component. That is, if ‘X’ is an essential property, no physical functional part can be a functional component without having the property ‘X’, and the physical functional component could no longer be a physical component, as soon as it looses the property ‘X’.

In software applications, we only deal with functional components and larger components are more useful, so as a first step I am only interested in discovering such essential characteristics of the physical functional components. This also eliminates possible conflicts and confusion in case of border or fringe cases and non-functional parts such as bolts, nuts, washers and other individual pieces of metal (e.g. panels for car such as bumper, bonnet or grill), plastic or glass (e.g. windshield glass or mirror). Of course, a functional component such as auto-engine may be created by assembling multiple pieces or parts of metal.

Let me provide background for how and why I started this research effort:

I accidentally stumbled onto a GUI library that is capable of implementing a class definition by encapsulating the application code for any GUI-application (where the class definition is referred to as RCC-Replaceable Component Class). These RCCs can be used to assemble these applications as sub-components to build larger and larger RCCs (for building larger and larger container-components). In this case, it required just 3 lines to assemble each replaceable component by using respective RCC, and the component can be effectively removed by removing the 3 lines. For example, this sample application is created by 6 such RCCs: http://real-software-components.com/CBD/City_GIS.html

After implementing application code for many small GUI-applications as RCCs, it was fascinating to see even junior developers able to build complex GUI-applications having hierarchy of replaceable components by using each of the RCCs to assemble each of the replaceable components. It induced irresistible curiosity more than 10 years ago and decided to focus on this research. Another thing, I felt (after creating hundreds of hierarchies of replaceable components) that the replaceable components are equivalent to the ideal physical functional components and each of the hierarchy of replaceable components is logically equivalent to the CBD-structure (one of the essential aspects of the CBD design of physical products). See CBD-structure: http://real-software-components.com/CBD/CBD-structure.html

This kind of experiments made me consider the possibility that it is possible to invent real components for software that are equivalent to physical functional components for achieving real CBD for software (e.g. by achieving a structure equivalent to the CBD-structure for any software application).

After careful observation of many large physical functional components, I believed, there exists a mysterious property that is uniquely and universally shared by each and every known physical functional component. I could not find any terminology to describe the mysterious property. After further research and making satisfactory progress and beginning to grasp the innate nature, I named the mysterious property ‘self-contained’, since I felt that the term “self-contained” roughly (or vaguely) fits the intended meaning of the mysterious property.

So I created a hypothesis that each and every physical functional component shares an essential property, which I named “self-contained”. I must validate this hypothesis for discovering the nature by employing a scientific process. I used the following method (which I believe is a widely used proven scientific method) to discover the intended meaning of term “self-contained”: http://real-software-components.com/RSCC/accurate_description_for_CP.html

I believe, any software expert can discover the intended meaning of ‘self-contained”, but it is not a simple task to discover the innate nature and the essential characteristics of the physical functional components. If this task is simple, software engineering would not be in this mess. For example, existing software engineering paradigm has been evolving for decades by relying on an erroneous postulation (or axiom or hypothesis), which defined the term ‘software components’ as an alias to ‘software parts’ either having useful properties (e.g. reuse or standardized etc.) or conform to so called component models. I believe, this task to discover is not impossible either. I believe, it requires few weeks of intense experimentation, critical analysis of facts and focused mind exercises or critical thinking (e.g. to overcome conformation bias, perceptions and basic concepts of deeply entrenched existing paradigm) to achieve gestalt’s shift.

Each large software application comprises of multiple ‘self-contained’ parts or modules. Since the essential property of ideal functional components is not yet discovered, today the chief software architects and designers of large software applications are not putting any conscious effort to identifying ‘self-contained’ parts or modules exist in the applications. I am proposing a new kind of CBD (Component Based Design) that requires identifying the multiple ‘self-contained’ parts or modules and implement the application code for each of the ‘self-contained’ parts or modules as an RCC (Replaceable Component Classes).

Each of the RCCs must require no more than 3 to 5 lines of code to assemble the respective replaceable component, and one must be able to effectively remove this replaceable component by removing the said 3 to 5 lines. It is preferable to not implement any more code for communication or configure each of the object instances of RCCs (i.e. replaceable components), so each replaceable components must rely on an intelligent CASE tool to collaborate with other components or parts of the container application. A internal implementation of a sample intelligent CASE tool is illustrated in FIG-3 at: http://real-software-components.com/CBD/Sample_SoA_CASE_tool.html

Therefore, the essential pre-requisite for the proposed CBSD (Component Based Design for Software) is discovering the essential properties of ideal functional components (of the physical world) to positively identify equivalent components in the context of software applications (a virtual world). That is, if the essential property is ‘self-contained’ (as I proposed), the software designer of an application must discover the intended meaning of the term ‘self-contained’ for positively identifying large self-contained parts in his software applications.

The primary differences between existing software design and proposed design for any large software application is: The chief designer must discover the essential properties (e.g. intended meaning of term ‘self-contained’) for positively identifying multiple ‘self-contained’ parts or modules. Implement each of the ‘self-contained’ parts or modules as a RCC, where each of the RCCs must rely on an instance of intelligent CASE-tool (included in the application by using a reusable class) for collaborating with other components and parts of the application.

It is not hard to implement a reusable class for the intelligent CASE-tool that can maintain coupling-interfaces of each of the components and facilitate communication between any two components by couplings the interfaces of components. Once a ‘self-contained’ part or module is identified, it is not hard to implement the application code in a set of exclusive files associated with a class definition referred to as RCC (in any modern Object-oriented programming languages such as C++, Java or C#).

In case of GUI-applications, the task of identifying self-contained parts or modules is less complex. In case of non-GUI-applications, the task of identifying self-contained components is more complex. That is, it requires lot more practice, knowledge and expertise not only on the innate nature of the component but also respective domains of non-GUI-applications.

However there is a catch-22 situation: In case of GUI-application, even though it is less complex to identify self-contained parts or modules, but no other GUI library (e.g. Windows/VC++ or Java/Swing) are designed to encapsulate application code of a self-contained component (e.g. a small GUI-application) such as City_LandMarks in a class definition. I am only saying that capability doesn’t exist in each of those GUI libraries (because the vendors of respective GUI platforms haven’t even heard of replaceable components). I am sure vendors of respective GUI platforms can quickly implement that capability, if they want to (e.g. if they discover the replaceable components and believe such RCCs are useful).

The most complex part for achieving real CBSD (Component Based Design for Software) is discovering the intended meaning of the term “self-contained”. Discovering the nature help the chief-designer to identify various parts and functionality or features of the applications that can be implemented as RCCs (Replaceable Component Classes).

Therefore, the trillion dollar question is: Is it possible to discover the nature and essential characteristics of ideal physical functional parts? I believe, the answer is absolutely YES! I am not saying it is easy to make this discovery. I am only saying that it is not impossible. I can’t give elaborate argument here, but let me give a simple argument (I am hopping smart people can connect the dots and fill any gaps or missing pieces). Also I appreciate finding any flaws or shortcomings to oppose (e.g. cons) or in support (e.g. pros) of the following argument.

Theoretically it is possible to discover nature (i.e. essential properties) of any physical being, including components. If attempted to discover the innate nature and essential characteristics, mankind never failed to discover the essential characteristics of any physical beings which can be seen and touched. A big part of basic sciences (e.g. chemistry, botany, zoology and physics) is to discover the nature (e.g. essential characteristics) of physical beings and (e.g. essential aspects of) phenomenon. Of course, mankind already discovered innate nature and essential characteristics of more complex and diverse species such as mammals, animals, plants, elements, atoms, molecules and bacteria etc.

Unfortunately it is impossible to find any evidence that researchers of computer science ever tried to discover the innate nature and essential characteristics of good old physical functional components (i.e. certainly a physical being) or essential aspects of good old CBD for physical products (i.e. logically a physical phenomenon). Without even trying and not even contemplating, is it wise to assume or argue that it is impossible to discover the innate nature and essential characteristics of good old physical functional components (i.e. certainly a physical being) or essential aspects of good old CBD for physical products (i.e. logically a physical phenomenon).

Let me name one of the exceptions that prove the rule: Scientists not yet successful in discovering the internal structure and nature of electrons, protons and neutrons (that are certainly physical beings), for which the scientists have been using string-theory to make this discovery. An example for a phenomenon the scientists not yet successful in discovering is origin of universe, for which the scientists are using theories such as big-bang-theory. It is very hard to find such rare exceptions. No one disputes the fact that, the right answer must be an objective Truth (if it is ever discovered). Although some experts might argue that it is impossible to discover the internal structure of sub-atomic particles, but all agree that there must exist a unique answer and the answer is an objective Truth. That is, no one disputes the very existence of an objective truth, only express doubt about mankind’s ability to discover the truth any time soon.

Hence there exists an objective Truth for the essential characteristics and nature of any kind of physical being including for ideal physical functional components. I can’t find any valid reason, why mankind can’t discover the objective Truth. We can’t see internal functioning of sub-atomic particles, but we can see internal functioning of ideal physical functional components. When tried, mankind never failed to discover the essential characteristics and nature of any physical being, even if they are 10 times more complex than physical functional components. Hence, there is no valid reason, why it is not possible discover the essential characteristics of physical functional components, if researchers of computer scientists try to discover innate nature of ideal functional components.

If an alien send to the Earth to find an elephant, the pre-requisite to successfully accomplish this task the alien must discover or know accurate description to positively identify the elephants. Likewise, designer of a software application must know or discover the accurate description (i.e. objective facts about the essential properties) of ideal functional components (in the physical world, in the context of the application domain) to positively identify equivalent software components (of virtual world – an alien landscape) in the applications.

Sorry for a long background and summary for the above question. If I am right, correct answer to this question would have profound impact on the progress of software engineering. I believe it is possible discover the essential characteristics of physical functional components. Also I believe it is possible to invent real components for software by having the essential characteristics.

The exiting software engineering paradigm has been evolving for several decades by relying on these untested premises (postulations or hypotheses), which are: Today each kind of software components is nothing but a kind of software part (or module) either having given useful properties (e.g. reusable or standardized etc.) or conform to a so called component model. Using one or more kinds of such so called software components is defined as a kind of CBSE or CBSD (Component Based Design for Software).

If it is possible to discover the essential properties and when the essential properties are discovered, the discovery not only exposes errors in above postulations (or untested premises or hypotheses) that sidetracked progress of software engineering for decades but also puts back the progress of software engineering on right tracks by allowing us to invent real components for software (for achieving real CBD for software, since logically real-CBD for software requires using real components for software).

P.S: This is posted at: https://www.researchgate.net/post/Is_it_possible_to_discover_innate_nature_and_essential_characteristics_uniquely_and_universally_shared_by_all_the_physical_functional_components#share

Best Regards,

Raju Chiluvuri

Most software experts lost their ability to grasp even simple facts, because they are brainwashed and deeply indoctrinated into existing paradoxical paradigm for over 40 years.

            Please kindly allow me to briefly explain basic facts about an ideal Component-Based Design (CBD): If a physical product has 100 functional components, each functional component can be designed and build individually by an engineer as best as it can be. Then each component can be plugged-into container component (or product) to build the product. For example, in case of a computing device, the components can be designed to plug-into a bare PCB (Printed Circuit Board).  For example, please refer to CBD-structure for logical structure of physical functional components.

            If any component doesn’t fit or function as expected, the component can be unplugged and refined individually little-by-little (can be tested by plugging-in) to make sure it fits properly and functions as required within the product. This process is repeated for each of the components (by the designers of the component individually) until all the components and the resultant product functions as required. The essential nature of any functional component is: The component is fully constructed by the engineers building each of the functional components and the engineers using the physical functional component (e.g. as a component or as a sub-component of another component) can just plug-in the component without any construction and with little or no configuration.

Of course, most of the useful products must be evolved for many decades by releasing better or improved models. The above product is evolved by evolving each of the components individually (e.g. by adding more and more functionally and/or features to each component). Also the product can be evolved by adding more new components for providing more functionality and/or features. Please refer to CBD-process.

            The above are the simple and obvious facts of CBD for physical products. That is, engineers of each component must be able to design, built and test their component individually. It is not necessary for the engineers of any component to see internal design any other components. In case of ideal-CBD, when all the components are unplugged (one component at a time), the product left with an empty PCB. Therefore, the ideal CBD achieves highest degree of modularization theoretically possible. It is not necessary that even a single component in the component-hierarchy to possess any properties (e.g. reuse, standardized or conform to any so called component models) erroneously attributed to so called software components known today.

            Of course, many software experts have no problem understanding the above ideal-CBD in the context of designing and building physical product such as an experimental super-computer. They have no problem accepting the facts that: It is not necessary that even a single component in the component-hierarchy to possess any properties (e.g. reuse, standardized or conform to any so called component models) erroneously attributed to so called software components known today.

They have no problem accepting the above simple facts of an ideal-CBD. But they would never accept these facts and nature in the context of software components and CBD for software. Many experts so deeply indoctrinated and brainwashed into existing paradoxical paradigm, they loose their ability to even see the above simple truths in the context of CBD of software products and software-components.

My research goal is to define an ideal-CBD for software products and achieve such ideal-CBD for software products, which must be equivalent to the ideal CBD for physical products. My research effort found a way for achieving this goal. This goal can be accomplished by using real-software-components equivalent to the physical functional components (where the real-software-components share essential properties uniquely and universally shared by each and every physical functional component).

That is, building software applications by taking a generic application template and plugging-in all the real-software-components. In case of ideal-CBD for software, each of the real-software-components must require no more than 3 to 5 lines of code to plug-in the real-software-component (even if the component has dozens of large sub-components). Furthermore, removing these 3 to 5 lines of code must effectively remove the real-software-component (without leaving any traces). The application must be left with generic application template, when all the software-components are unplugged (by unplugging one component at a time).

Unfortunately, software experts fail to grasp the simple fact about the real-components: The builders of each of the physical functional-component can only focus on the internal design of just one physical functional-component without any distractions, since it is not necessary for them to see internal design of any other component (not only during initial model for first release but also for each of the successive models throughout the evolutionary life) of the product.

In case of software, it is not necessary for any engineer responsible for either implementing a component for first release or evolving by improving a component (i.e. RCC) for successive models to see even a single line of code implemented for any other component in the software application. Another essential requirement of a real-software-component is that the component must be unplugged effectively by removing 3 to 5 lines (even if has hundred sub-components). Only real-software-components can satisfy the second requirement, because reusable GUI-classes for GUI-components satisfy the first condition but can’t satisfy the second condition, because one must implement many lines of application code not only for accessing and processing the application data but also for using the data to construct and configure the instantiated GUI-object to assemble a GUI-component in an application.

Let me define 2 essential conditions for real-software-components (or ideal physical functional components) are: (i) The designers or engineers of any component must be able to focus on code-base of just one component without being distracted, for example they should never see even a single line of code implemented for any other component (not only during initial model for first release but also for each of the successive models throughout the evolutionary life) of the product. (ii) One must be able to plug-in each of the real-software-components by implementing just about 3 lines of code and one must be able to effectively unplug the component by removing the 3 lines. That is, no real-software-component requires implementing any more associated code, for example, either to construct or configure the component.  It is desirable to eliminate necessity of implementing even communication code by using intelligent CASE-tools.

The so called software component known today breaks the second condition. For example, reusable components (e.g. GUI-classes for presenting GUI-components such as Pie, Line or Bar charts) satisfy the first condition, but can’t satisfy the second condition. In general, the real-software-components are custom designed to satisfy unique needs of target application (so can encapsulate or packaged all the application logic in a replaceable container/package that can be plugged-in and unplugged) and self-contained, so requires little or no application code (e.g. for construction and configuration etc.) after plugging into its target product. This second condition is extremely important distinction between real-software-components and other kinds of so called software-components known today.

For example, kindly review a sample City_GIS application that is build by plugging-in just 6 large functional components. Of course, large applications might contain 100s to 1000s of such plug-in components. Since the real-software-components are custom designed to satisfy unique needs of target application, it is possible to design and build larger and larger real-software-components as plug-in components (that needs just 2 or 3 lines to disassemble or re-assemble) as illustrated by CityLandMarks (having 3 sub-components). It is not practical to design CityLandMarks to be reusable in multiple applications, because to make such components reusable, each component must be designed to be context-independent and must be configurable to context of each application (which requires implementing code for using application specific data).

Furthermore, nearly 100% of the application code for any application (e.g. City_GIS) can be implemented as real-software-components. The real-CBSD could eliminate 100% of the spaghetti code, since designers of each real-software-component can focus only code base of just one real-software-component (without being distracted by even single line of spaghetti code implemented for any other component in the application).

Each and every known physical functional-components satisfy two important conditions outlined for real-software-components above. Therefore, over 90% of the functionality and features of any complex physical product can be implemented in physical functional-components. Each engineering team can work on each of the functional components individually (without being distracted by noise or spaghetti code), even if the product has 1000s or tens of 1000s of functional components.

The manthra of real CBD for physical products is: Allow the designers of each functional-component to focus on internal design of the component, by eliminating 100% of noise or interference (by shielding them from exposing internal design of any other component). The manthra of real CBD for software products is: Elimination of 100% of the spaghetti code from the application, by partitioning all the functionality and features of any large application into hierarchy of real-software-components.

Partitioning any complex product into hierarchy of replaceable components eliminates huge accidental complexity and allows engineers to just focus on essential complexity. In case of complex software today, nearly 80% of the efforts of software engineers are wasted on accidental complexity. The real-software-components can be invented for achieving ideal CBD for software by discovering essential characteristics uniquely and universally shared by each and every physical functional component. The discovery of essential characteristics also helps experts realize that they were brainwashed and indoctrinated into existing paradoxical paradigm.

Urging software researchers to discover real-CBSD and set the goal to achieve real-CBSD for large and complex software products

Toady CBSD (Component-Based Software Design) or CBSE (Component-Based Software Engineering) is defined as using so called software components. It is not much different from defining flying is not much more than flapping wings, by alien species who have not yet discover ‘what is real flying’. Why is it not possible to discover the beauty and grace of real flying by observing aerobatic maneuvers of majestic birds (e.g. Peregrine Falcon, Golden Eagle etc.) chasing a prey or modern Jet-fighters in a dogfight (e.g. by watching videos)? Likewise, Why is it not possible to discover the beauty and grace of ideal-CBD and ideal-CBE (by investigating and analyzing all the facts to discover essential aspects uniquely and universally shared by the design of each and every complex physical product built by assembling physical components)?

Please let me describe an ideal CBD, since I believe it is possible to achieve the ideal CBD for designing and building complex software products. An ideal CBD of any complex product requires partitioning the product into hierarchy of replaceable components, where the term replaceable means that the component can be easily disassembled and reassembled as a unit. The FIG-2 in CBD-structure illustrates a logical structure of the components, where even a container component can be unplugged as a unit and disassembling the container component effective removes all it subcomponents from the product without leaving any traces. It is important to comprehend and always keep in mind the 3-CBD-facts and 3-CBD-rules.

In an ideal CBD, no component must take more than few minutes for disassembling by unplugging the component and must not take more than few minutes for reassembling by plugging-in the component. In ideal CBD, one must left with bare board (e.g. PCB board having holes to plug-in pins of each component), if all the components are unplugged (by unplugging one component at a time). In general, a team of engineers build each of the large and complex products, where each engineer is responsible for designing and building one or more components in the hierarchy of the replaceable components.

In case of ideal-CBD, no component should be too complex to require effort of more than one engineer. Each component should be of optimal complexity and allow each engineer to work in a manner consistent with his skills, expertise and talent. It is useful to define an optimal complexity, for example, an average newly recruited engineer should need no more than couple of weeks to grasp the design of a large component to safely make simple changes (e.g. to add simple features and functionality).

Each component can be designed developed and tested independently outside of the product. Once satisfied with its quality and functionality, the stable version of the component can be assembled into the product to make sure it performs as expected in the product. Furthermore the component can be refined little-by-little until it performs optimally within the products (e.g. by perfectly collaborating with other components), which results in yet another stable version of the component.

This stable version of the component can be refined and tested independently outside of the product for adding more features or functionality for creating yet another stable version of the component. This version of the component can be assembled into the product to make sure it performs as expected in the product. Furthermore the component can be refined little-by-little until it performs optimally within the products (e.g. by perfectly collaborating with other components), which results in yet another stable version of the component.

For example, the sample City_GIS application achieved the ideal-CBD (Please also refer to important FIG-3). A source code control system SCCS or RCS/CVS can be and must be used for tracking the code base of each of the components, so that it is possible to restore any of the older versions of the components. For example, if an engineer wishes to experiment by adding few features he feel useful and creates a new version, but only 40% of the customers liked it, he could restore the older version. For example, a junior engineer joined and need to add few more features and in the process the code base of the component is ended up sub-optimally by the time he gained enough experience in the domain, he could restore older version and restart again.

In case of real-CBD, each component have exclusive blueprint (e.g.code-base) than can be versioned and sandboxed. Hence no engineer can damage design (e.g. code base or blueprint) of any other component. But in case of software, even a simple application having just three large components begin its life as spaghetti code. That is, each file contains code-sections for more than one component, so finding and redesigning code sections of any component is a complex task. Then to test the component, one must test whole system. If one wishes to restore older version, he must restore the all the files (which result in loosing changes made to other components during this period in those files).

Some of the benefits of real-CBD include: Each component can be optimized (e.g. re-factored) and tested independently. More than one version can be maintained for each component, to address different segments of customers. The real-components are often by nature neither reusable nor standardized, since each of the components are custom designed to optimally satisfy unique needs of its target application (and also must be adoptable to unpredictable evolving unique needs of its target application).

However, if another new product-model requires similar component, the blueprint (e.g. code base) of an existing component can be redesigned to create a customer version for the new product-model. Hence real-software-components offer excellent knowledge and code-base reuse. Today, it is not practical to reuse the knowledge and code-base, since the code-sections of large software components are spread across many non-exclusive files, where the files comprise code-sections for multiple components.  We invented a GUI-API, which allow encapsulation of any complex GUI-component is a class definition, which makes the component not only replaceable but also code-base for the GUI-component can be encapsulated in an exclusive set of files for versioning and sandboxing.

The above kind of GUI-API is one of the essential missing pieces for inventing real-CBSD. Other inventions essential for real-CBSD/CBSE include: An ideal CBSD/CBSE requires employing intelligent CASE-tools that must automate creation and management of communication code by managing coupling interfaces of each component for automatically detecting any incompatibilities between coupling interfaces of any two components.

After creating hundreds of component-hierarchies (many of them I am more than eager to demonstrate to fellow researchers), I can’t find any valid reason why designers of complex software products can’t achieve CBD-structure for most of the large and complex products. I strongly request software researchers to discover essential aspects uniquely and universally shared by design of each and every large CBD-product for discovering inherent nature of real-CBD; and discover essential properties uniquely and universally shared by each and every large functional-component for discovering inherent nature the functional-component.

Unfortunately substantial research effort has been wasted in past three decades for chasing goals that are not much less than science fiction by relying on baseless axiomatic postulations (which are not much less than myths). For example, a goal chosen in formative years during mid 1960s of software engineering was: building software as we build computers by assembling reusable components from third party vendors. Even a quick analysis of obvious facts and simple observations conclusively prove that it is impossible to achieve such a fantasy.

Essential & Accidental complexity of Software Engineering: Eliminating “Cognitive Dissonance” is a silver bullet

This is continuation to this previous blog dated 26th Nov, 2013. It is useful to read up to the point where the previous blog refers “Cognitive Dissonance”. Today “cognitive dissonance” for each SCC (i.e. component) builds up as more and more spaghetti code is added for other SCCs in the application. In case of real-CBD, componentization and hierarchy of components eliminates such cognitive dissonance. That is, componentization (i.e. encapsulating each SCC in a RCC) allows focusing on a given problem at hand (i.e. each of the RSCCs in the component-hierarchy), without any overbearing interference and huge distractive noise from surrounding issues (i.e. code sections for other SCCs).

The CBD-structure(or hierarchy of replaceable modules) is single most essential aspect universally shared by each and every large physical CBD-product (exists today or in the future). If I were designer of Hard Drive or Power Supply of an experimental computer, how long would it take for me to find the all the parts (i.e. devices) of such large container component for a making minor redesign to the component or to replace the component? It would not take more than few minutes to find the component for either replacing the component or to redesign and test the component individually outside of the product.

Today the computer is designed as shown in FIG-2, as a hierarchy of replaceable modules, where each component can be disassembled (or plugged-out) and re-assembled (or plugged-in) in mater of minutes. But imagine if the computer were designed as shown in FIG-3, where each device of a large component (comprising hundreds of devices) is hard wired into the system-board along with the devices for other such large components (comprising hundreds of devices). The FIG-3 illustrates, how complex software having multiple SCCs is being designed today. It is essential to keep in mind that even large components (i.e. SCCs) by nature can be loosely coupled, while other kinds of parts (even small parts) used for building large components by nature tightly coupled.

Compare the cognitive dissonance for the components in a CBD-structure with the cognitive dissonance of a large software component such as City_ATC having 5,000 lines of code or container component such as City_Landmarks having 15,000 lines of code in a medium size application having 500,000 lines of code. How long it would take for me to find all the code-section for City_ATC that are spread across multiple non-exclusive files after a gap of few months to redesign the component? Is it practical to effectively remove all the code-section to effective remove the component? What is the cognitive dissonance for a newly hired software engineer?

Compare the cognitive dissonance for above components (i.e. City_ATC and City_Landmarks), if each of the components is designed as a RCC and assembled into the application by implementing 2 to 3 lines as illustrated in Listings-1 and Listings-2 (where the coupling interfaces and communication code are respectively managed and created by an intelligent CASE-tool).

The cognitive dissonance of each component represents non-essential or accidental complexity wasted for making a small change to the component. In his famous seminal paper "No Silver Bullet — Essence and Accidents of Software Engineering" Dr. Brooks persuasively argued that there is no ‘cognitive dissonance’ (i.e. accidental complexity) and/or not possible to eliminate ‘cognitive dissonance’ (i.e. accidental complexity).

I respectively disagree based on the easily verifiable 3-CBD-facts. His famous seminal paper and famous book “Mythical Man Month” has huge influence on shaping software engineering research and our belief that software is unique/different and all the complexity is essential (so not possible to eliminate). This is true in the existing paradigm, which is build by relying on a huge error that prevented us from discovering innate nature of real-components.

However discovering unique essential characteristics universally shared by the physical functional-components not only expose the error but also help invent real-software-components equivalent to the physical functional-components for achieving real-CBD (e.g. CBD-structure) for eliminating cognitive dissonance for each of the components in the component-hierarchy. I always admire and still a big fan of Dr. Brooks, but I have to respectfully disagree with him now (based on my recent discoveries).

Few years back in his email response to me, he said that reasonable people can disagree. Unfortunately I have to even disagree with that statement, since in the context of basic science there can be only one accurate answer for nature of physical beings (e.g. diverse spices of components or animals) or physical phenomenon (e.g. CBD or controlled powered flight). The laws of nature are immutable and they can’t be changed or defined by a committee (as we have been doing by defining many kinds of so called software components & CBSDs).

Can respected scientists disagree, if the Earth or the Sun at the center, without any scientific basic and factual support. Can the scientist debate or disagree on Newton’s laws of motion, without any scientific basic and factual support? Therefore, I believe that the scientific process is broken in the computer science and that must be fixed: http://real-software-components.blogspot.in/2013/11/the-process-of-scientific-research-is.html.

Of course, respected scientists still could say that all this is just a theory, so there still could be flaw. But I don’t know what kind of excuse possible, when I can show practical results by demonstrating countless applications created as hierarchy of replaceable components on my laptop? I created hundreds of applications as hierarchy of replaceable components, when I accidentally discovered replaceable components more than a decade ago, which induced irresistible curiosity that driven me to focus on this long and arduous research.

The scientific process is broken and to fix it I must find real software scientists & researchers who really care about science & technology

The CBD (Component-Based Design) is not a peripheral issue or afterthought, but the very heart of designing and building complex physical products (either in step-1 or step-3 of CBD-process). Although physical components and CBD are taken for granted (as free oxygen in the air for breathing), its value would be realized if designers of complex physical products are prevented from using components and hierarchy of replaceable components for designing complex one-of-a-kind physical products (e.g. experimental automobiles, jet-fighters or spaceships) either in step-1 or step-3 of CBD-process (e.g. designers of physical products face crisis even larger than the crisis being faced by the designers of software).

The software industry is inventing hundreds of new kinds of software products each year. Likewise, mankind is inventing many new kinds of products each year. For example, please click here to review the design of a physical-product artificial-kidney that is in the process of being invited. This CBD-process must include (i) partitioning the product into hierarchy of replaceable components (i.e. CBD-structure), (ii) designing and building each component individually and (iii) periodically assembling the components to build the product to make sure that the components are functioning as intended and the product design is progressing as expected.

The process of designing any (software or physical) product and each of its large functional components is an iterative process, where each component is improved individually little-by-little to make it as best as it can be. No large functional component is neither magically works perfectly first time nor magically appears in a fine day. For example, in case of City_GIS application on the first day each component is empty whitespace or a pretty-GIF image as a place holder. In the next first iteration, if we assemble all the RCCs, only 10% to 20% of the features might be working in each of the components.

Today no other GUI-API is capable of encapsulating such large SCC in a RCC. If each SCC is not encapsulated in a RCC, the custom application code implemented for the application would begins as a spaghetti code even in the first iteration (having 15% features), since many application files contain source code for more than one SCC. This spaghetti code grows each day as each developer adds more and more code each day (in the non-exclusive files). No component can be tested individually, for example to test newly added features. So it makes nearly impossible to predict what sort of effect a small change in the custom application code of a SCC would have on other parts of the ever growing spaghetti code (comprising application code of all the SCCs of the application). In this case, each file comprises code-sections for multiple SCCs and code-sections for each SCC spread across multiple such files.

See: Cognitive dissonance: Essential & Accidental complexity of Software Engineering

Any changes made for unpredictable future needs, wisdom gained from use-cases, changing technologies or sparks-of-innovation would cost many times more, while adding more and more spaghetti code to one or more of these files. For me, most of the innovation-sparks come after completing 80% or most of the implementation (because I gain more and more insights and expertise as I work every day by intensely focus on each feature and problem domain); or by looking at how the features are being used by users, and feedback of users help me realize what matters most to them in day-to-day use. I am sure, the basic need for agile program is to provide a mechanisms to make incremental improvements.

Today's spaghetti-code is worst possible mechanism for agile-programming. The componentization of a complex problem into hierarchy of replaceable self-contained modules is most effective and efficient mechanisms known to mankind for improving each module little-by-little to make it as best as it can be individually. I am repeatedly using phrase "refining each component 'little-by-little'", which is from famous book on Evolution of Useful Things; and also using phrase  "making each component 'as best as it can be' individually", which is from video of designing new artificial-kidney. This is the only way for useful components to get closer and closer to perfection. A product can get closer and closer to perfection by making each component gets closer and closer to perfection.

Please consider this spaghetti code in contrast with the CBD of any physical product or City_GIS that is partitioned as hierarchy of replaceable components. The source code for each RCC/SCC is implemented in a set of exclusive files, where the exclusive files do not contain code for any other SCC. I can readily find all the code for each SCC even after few years, if I need to add more features (I don't need to see even a single line of code for any other SCC in the exclusive files of it's RCC). Each component can be tested individually outside of the product. If it works outside as expected and interfaces are not changed, it works predictably when assembled.  It is much simple to predict the impact of even extensive redesign of a RCC.

In case of software, most of the need for such need for prediction or guessing by using intelligent CASE-tools to manage and automatically detect any changes resulting in inadvertent incompatibilities in the coupling interfaces. So real-CBD for software can be far superior than CBD of physical products, once real-software-components are discovered.

True componentization requires sandboxing and versioning of each component for refining little-by-little individually to satisfy evolving needs. An ideal mechanism for agile-programming must let the programmer focus and work only on essential complexity, by eliminate all the non-essential overhead (or accidental complexity). For example, in case of physical components, the designers can disassemble each component and can focus only on the component. If each SCC is not encapsulated in a RCC, the spaghetti code (e.g. code-sections of other SCCs) surrounding the code-sections of the SCC adds  huge amount of accidental complexity.

The replaceable-components offer many other kinds of benefits, such as experimentation (which is extremely useful for innovations). For example, if I had a spark-of-innovation and asked an engineer to redesign a component and he ruined the code structure due to inexperience or a big customer prefers older version, I can still restore older version of the RCC in minutes from version-control-system. It is not practical in the existing spaghetti code, since each of the files that contained code-sections of the SCC also contain other code-sections for other SCCs and these other code-sections likely have been changed for redesigning the other SCCs.

It is not possible to list all this kinds of benefits of real-components and real-CBD, but it is sufficient to say componentization and hierarchy of replaceable components offer perfect mechanism for agile-programming. Many software experts give baseless excuses that software is different, because we can't see or touch each component as we can do with physical components. If I am designer of City_ATC of City_GIS, why can't I see or touch? I can touch and see any software component better than, I can see or inspect the circuits in semiconductor-chips. One may think and argue, they are different things. But please understand that I know what I am talking about (it is a long story, but let me briefly explain why I am qualified to say this):

I worked for Advantest (the largest test equipment company) for more than 3 years designing software for parametric testing of IC-chips. Parametric testing requires inputting test values at input and testing output (0 or 1 by using a given range of volts) after waiting some time (to allow propagation delay). The wave-forms at both input and output are highly analog (can take a range of values). I also worked for KLA-tencor (the largest maker of optical inspection equipment) and I was responsible for a software product called KLA25xx, which was installed in 90% of the semiconductor-fabs in the world during mid-1990s.

The inspection equipment of KLA-tencor optically-inspected the chips at various steps of manufacturing and stored defects and images in software product KLA25xx (e.g. for online monitoring at real-time and offline analysis for improving the process at later time). I was solely responsible for this product for 4 years and intimately knew each and every module of this product. It is amazing that each computer is working perfectly, when billions of things could go wrong in imperfect etching of the circuits and resultant analog waveforms due to even minuscule imperfections in etching. So it feels silly to hear such excuses that, we can't see or touch software. I can see RCC of my City_ATC far better than I can see circuits. I can use debugger tool to step through each line of code. if I need to add more features one year after releasing the City_GIS, only thing makes my life miserable is searching and finding all the sections of the code spread across the spaghetti code in ever changing non-exclusive multiple files for other SCCs, if the SCC is not encapsulated in a RCC (exclusive files).

On the other hand, today even large physical functional-components are designed as software. The soft-design of the physical components are called blueprints. The designers of physical components redesign each of the blueprints to redesign each of the physical-components, such as engine or gearbox of cars. Many of the components for Boeing Dreamliner or Airbus-380 are designed and tested as blueprints. The component interfaces and compatibilities for Airplane models are validated using CAD-tools similar to our proposed intelligent CASE-tools. Once real-software-components are discovered, I feel no one could see much difference between designing and building physical functional components and software components. The real-software-components certainly shall have clear and distinct advantage, because we can design software components more intelligent than mechanical components made of metals (e.g. for collaborating with CASE-tools to automate couplings).

I can write this kind of things endlessly (if any one has intellectual curiosity and cares to know), and for many aspects I don't even know where to start. If one wanders for 10 years in an vast uncharted area no one else don't even know exist, one get to learn very little about countless new species (i.e. thing or aspects) belongs to the ecosystem of this new vast uncharted area (or new paradigm). It is much bigger that one man or even 100 men could explore. I am eager to make the world aware of this vast uncharted area and start exploring countless possibilities.

I found my treasure (i.e. patents for real-software-components), but it is just a beginning and I feel other early explorers would find other treasures (and I am hoping that other treasures won't undermine value of our patented treasures). Although it is not simple and challenging to master such Kuhnien paradigm-shift, I am sure there shall be plenty to go for early explorers, who took the challenge. I feel, if I am successful in exposing this huge error, most software experts would be forced to master this new paradigm sooner or later (either by choice or for survival in the long-term).

The main question is when and how I could succeed in exposing the error (if ignore the possibility that I might fail). The next question is, if the US leverages or left to a foreign competition to exploit these new discoveries. India has only few research organizations and researchers, and I found most of them are devoid of any accountability (i.e. they simple don't care, and most are busy self-promoting before their political bosses, since top posts are political appointments based on cronyism than merits).

I am beginning to feel the US research organizations are becoming as bad as Indian research organizations. There is no way for making the research organizations aware of this kind of huge errors. For example, if we try to call, executive secretary answers phone to say he is very busy. Although the job of SEI of CMU and SDP of NITRD is to search every cave and even far corners for this kind of basic discoveries and must be shocked to know this kind of huge error and scramble for finding reasons for breakdown of basic scientific process. Instead they refuse to pay attention or listen to what I wanted to say.

The scientific process is broken, so we can and must fix it, by making real respected researches aware of broken scientific process and resultant huge errors. How or where can I find real software scientists & researchers who care about science & technology?