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
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?
