How can I expose huge errors in seed axioms of computer science and resultant software engineering paradigm?

Please kindly understand why I am having trouble in exposing these huge errors in seed axioms of a complex deeply entrenched paradigm. Since exposing the error in the seed axioms of geocentric-paradigm 400 years ago, I can’t find another example where scientists made such huge error in basic axioms and depended on the erroneous untested axioms (by assuming that the erroneous untested axioms are facts) for nearly half a century for advancing a very popular field such as software engineering.

Untested axioms (having errors) but are considered to be facts:

1.    Each kind of software part or module either having certain characteristics (e.g. reusable or standardized etc.) or conform to a so called component model is defined as a kind of a software component.

2.    Using one or more kinds of such so called software components is defined as a kind of CBD for software.

Let me get to the root of the problem. Every useful engineering concept and invention (i.e. engineering, chemical, pharmaceutical, medical, biotechnology or biological inventions) known to mankind is rooted in scientific facts. The knowledge of scientific facts forms the foundation to the inventions and concepts of engineering and applied sciences. Each engineering invention or concept is derived from a set of facts (i.e. selected from a large base of scientific knowledge) by applying sound reasoning and logic. No such invention could work and any engineering concept ends up in crisis (and flawed), if there are errors in any one of the facts and reasoning or logic.

Every engineering invention and concept is rooted in proven facts and derived by using reasoning and logic. It is impossible to find an exception to this rule in any other engineering discipline, except the definitions for nature and characteristics of the so called software components. These untested axioms (i.e. definitions for so called software components) are made from thin air, without any basis in reality or facts (e.g. by ignoring all the reality and obvious facts known to mankind about the physical functional components). Only basis for the axioms is desire and fantasy of building software by assembling reusable components (as mankind has been building computers). Please review few paragraphs, if you like to see couple of sample invention derived from scientific facts: http://real-software-components.com/forum_blogs/BasicScientificPrinciples.html

In case basic science (e.g. botany, zoology or chemistry) the scientist accumulate the scientific facts. The researchers of applied sciences or engineering rely on the knowledge of the facts and apply reasoning and logic to derive concepts for applied sciences (e.g. engineering, biotech, medical or pharmaceutical fields) to make useful inventions. Few exceptions to this rule are discovery of penicillin or X-ray, which are invented accidentally and applied reasoning and logic to discover scientific facts. These scientific facts helped invent many other kinds of antibiotics or X-ray machines. But ultimately all the concepts and inventions are rooted in the scientific facts.

You may skip this evidence, but it is possible to prove that the axioms are just science fiction: http://real-software-components.com/CBD/main-differences.html AND http://real-software-components.com/RSCC/ecosystem-evolution.html

Please kindly assume this: It is possible to discover essential properties or characteristics uniquely and universally shared by each and every known physical functional component; and also assume that the essential characteristics are {C7, C9}. Please let me define, what an essential character is: No physical part can be a component without having the essential character and the component can no longer be a component, as soon as it looses the essential character (or property).

If such essential characteristics exist for physical functional components and if it is possible to invent equivalent software component (by having the essential characteristics), logic dictates that no other kind of software parts (or modules) can be software component. It is possible to validate the facts and logic for inventing real software components using many other independent ways.

For example, the following is one of many ways to independently validate the facts and reasoning or logic used for inventing real software components: If it is possible to discover essential aspects of uniquely and universally shared by CBD of physical products and the essential aspects are {A3, A6}. If such essential aspects exist for CBD of physical products, logic dictates that the using real software components must result in equivalent CBD for software products (or CBSD), where the real CBSD must shares the essential aspects {A3, A6}.

I discovered such essential characteristics {C7, C9} for physical functional components for inventing real software components that are capable of achieving real CBD (having {A3, A6}) for software products.

The discovery that ‘the Sun is at the center’ implied no other planet can be at the center, which exposed the error in then deeply entrenched axiom ‘the Earth is at the center”. Likewise, this discovery of essential properties implies that no other kind of software parts without having the essential properties {C7, C9}, can be a real component for software (and using such fake software components can never achieve real CBD for software products). Furthermore, discovering the essential aspects of physical phenomenon CBD for physical products to make sure the real software components achieve a CBD for software (i.e. sharing aspect A3 and a6), which is equivalent to the CBD for physical products.

If the above seed axioms for software engineering are not made out of thin air, kindly provide the scientific facts and reasoning or logic used for deriving the axioms. Please forgive me, if the following facts appear arrogant or disrespectful:

The researchers of software engineering wasted billions of dollars and few decades of passionate research by relying on those untested axioms (by erroneously concluding that the axioms are facts). This passionate research (i.e. brute force) spanning many decades for advancing software engineering resulting in a complex paradigm and altered reality (i.e. a paradox). Today software engineering researchers are unable to come out of the paradox and lost their ability to see reality about ideal CBD of physical products and nature of ideal physical functional components.

These erroneous concepts are being taught to impressionable students in class rooms resulting in indoctrinating each new generation in to the paradox (or cult) and later years of experience of using so called software components and CBSE permanently altered the perception of experts (preventing them from seeing of reality). Establishing a new theory is tough; making changes in an existing theory is tougher, particularly when the changes are suggested in a field that had originated nearly half a century ago, and hundreds of books and thousands of articles have meanwhile been published in that field the world over.

I discovered that the essential characteristics for ideal physical functional components are (i) Replaceability (i.e. the component can be disassembled as a unit by removing 3 to 5 lines and re-assembled by implementing by removing 3 to 5 lines) and (ii) Self-contained. So this component is also referred to as RSCC (Replaceable Self Contained Component).

The ability to positively identify is a tacit knowledge that can be and must be acquired: It requires few weeks for analyzing hundreds of functional components in light of equivalent software components for discovering intended meaning of the term ‘Self-contained’ with respect to software (and for acquiring necessary tacit knowledge and tacit expertise for positively identifying multiple SCCs in each large software application).  But in brief, a RSCC is a component custom designed for just one target application, so that the component doesn’t require any more construction or configuration code (i.e. it should require no more than 2 to 3 lines to assemble the component, and removing the 2 to 3 lines must effectively remove the component without leaving any more traces of code associated with the SCC (where the associated code includes communication code or code for getting any data to construct or configure the replaceable component).

Today any large custom application requires implementing tens of thousands to hundreds of thousands (or even millions) of lines of custom application code, even after using all the tools and libraries. Each of these applications comprises multiple ‘Self-contained’ components (or SCCs). When it is impossible to reduce the custom application code (e.g. by using any other kinds of tools or library), the real CBD for software recommends identifying multiple SCCs in the application and implementing the application code of each SCC as RCC (Replaceable Component Class) to make the SCC a RSCC.

Please kindly allow me to illustrate a sample application that is built by assembling real-software-components and achieved real CBD for software: http://real-software-components.com/CBD/City_GIS.html

This sample City_GIS application has just 6 large components, where no component requires more than 3 lines to assemble. In this application, no component requires implementing any more communication code, because each component implements necessary communication code to use the intelligent CASE tool to collaborate with other components and parts of the application: You may find a sample  intelligent CASE tool in FIG-3 at: http://real-software-components.com/CBD/Sample_SoA_CASE_tool.html

Today code base (i.e. all code sections) of almost no large ‘Self-contained’ part (or SCC) is implemented as RCC (Replaceable Component Class) by conscious design effort. That is, the RCC is a new kind of component, so designers must put conscious effort to identify the SCCs in the application. Our CBSD requires identifying multiple SCCs and implement each SCC as a RCC.

If all the SCCs are identified, over 97% of the application code can be implemented in one of the RCCs. In that case, if an application has 200 SCCs and 200 RCCs are implemented (by designing and testing each RCC independently), the application can be built by assembling all the 200 components within few hours.

If the average size of the RCCs is 2500 lines, then total size of the custom application code is 500,000 lines (200*2500). Today this 500K lines end up as spaghetti code (even in case of most optimal design), in multiple non-exclusive files, where the non-exclusive files contains code-sections for more than on SCC. In case of our CBD, these 500K end up in 200 RCCs, where each RCC can be redesigned and tested individually (at any time in the future to add more features, for example, to release future versions of the software application).

Today both cases (existing paradigm and proposed paradigm), requires implementing 500K lines (if code base can be highly optimized). In our case, each SCC/RCC is designed and tested individually as an independent application, so code base end up in exclusive files (i.e. no file contains code for any other part of the application). It requires far less effort to re-factor code base of each RCC to make the overall design optimal. In case of existing paradigm, in reality it is not practical to optimize the code base of the application, so the code for the application could end up 600K+.

I have been passionately doing research on the nature of functional components and CBSD for more than 12 years, after accidentally discovering RCCs and creating 100s of replaceable components and hierarchy of replaceable components (during 1999 and 2002). So I can justify each and every aspect or statement.

Dr. Brooks predictions and laws hold for another 1000 years, if it takes 1000 years to expose this error in seed axioms. The error might appear very small, but it is a huge error and no meaningful progress is possible until this error is exposed. For example, 500 ago no one realized the implications of exposing the error in the seed axioms of geocentric-paradigm. Many philosophers even argued that it would have little or no effect on the advancement of scientific fields.

We can find irrefutable proof that, an error in seed axioms always sidetracks scientific progress. Exposing the errors in the seed axioms puts the progress on the right track and often its implications would be apparent when next great discovery is made by traveling on the right tracks. For example, it was impossible to discover Gravity or Newton’s laws of motion without putting the scientific progress on the right tracks by exposing the erroneous seed axiom for geocentric-paradigm.

It would not be hard to predict the future of basic sciences for 16th century philosophers, if the error in seed axiom “the Earth is static at the center” were not exposed until now. But how could they predict future or “E=M*C-Squared”, fusion bombs, gravity, computers, fiber optic networks, cell-phones and quantum mechanics? Software engineering has been stuck in the rut of spaghetti code and not going anywhere for nearly three decades. It will continue to be stuck in the rut until the errors in the seed axioms are exposed.

It is impossible to invent real CBD for software products without inventing real software components. It is impossible to invent real software components without discovering scientific facts such as the nature and essential properties of the physical functional components and nature and essential aspects of the CBD for physical products. The CBSE researchers must acquire this kind scientific knowledge and then apply sound reasoning and/or logic for (i) inventing “real components for software” and (ii) deriving concepts for “real CBD for software”.

I request researchers to kindly provide the scientific facts and reasoning and/or logic used for deriving the above seed axioms of software engineering, If the axioms are not made out of thin air?

Is any such useful concept or invention (e.g. in any discipline of applied science such as engineering, chemical, pharmaceutical, medical or biotechnology) during past 150 years made out of thin air? Is it possible to find any useful engineering concept or invention created by mankind that is not rooted in a set of scientific facts or derived by applying flawed reasoning and logic by relying on the facts?