Saturday, November 28, 2015

Software researchers are blinded by their prejudice
and confirmation bias. They refuse to consider the possibility that definitions
based on their flawed assumptions about the essential property and nature of
the physical components might be wrong (e.g. nature of components is not reuse).
One can even convince a devote priest, a possibility that there is no God. But one
can’t make software researchers to see the obvious reality and investigate
Truth: http://www.researchgate.net/publication/284167768_What_is_true_essence_of_Component_Based_Design

I contacted hundreds of researchers and they used
every possible excuse in the world to avoid their obligations and sacred duty,
which is to investigate the Truth and Reality. Pursuit of absolute truth is not
only an obligation of real scientists but also a sacred duty. They made up
their mind and not open to rational reason or investigating Reality. Simply they
are refusing to know reality to investigate Truth. This is how members of any
cult behave.

It would send shockwaves across research community of
any mature scientific disciplines, if one of the basic discoveries or axioms
(considered to be self-evident fact) at the root of a major sub-discipline of
any mature scientific disciplines has never been tested and might be flawed.
The software researchers justify their relying on untested axiom by saying that
the computer science is not real science and/or software engineering is not
real engineering. If that is true, why do they pretend that they are scientists,
researchers and/or engineers? Instead of blocking the progress of knowledge,
they must have integrity to allow real scientists to investigate the reality. If
computer science is a religion they must be priests. If computer science is a cult
they must be cult leaders.

Even the basic sciences were not real science until a
flawed axiom (considered to be self-evident fact) at the root was exposed. Saying
that the Sun is at the center (500 years ago) offended common sense and deeply
entrenched conventional wisdom. The philosophers (scientists referred to as
philosophers) blinded by their prejudice and confirmation bias, choose to
impression Galileo for life rather than investigate reality by looking through
his telescope.

If the philosophers were wrong (i.e. a cult) for
relying on untested axiom (i.e. the Earth is static) until 500 years ago, software
researchers and scientists were also a cult for relying on axiom that were
never tested. No one can name, who discovered and who proved the definitions
for so called software components and CBSE. If I am wrong, where can I find the
documentation for the proof? Defending and relying on untested axioms (by
insisting the axiom is self-evident Truth requires no validation) is not
science but a cult.

History proved that no real science can ever be
created by relying of an untested flawed myth (by concluding that the myth is
self-evident truth requires no validation). How any one can pretend to be
scientists/researchers, if they insist that there is nothing wrong in relying
on untested fundamentally flawed axiom for advancing the our knowledge (e.g.
when there is no evidence exists to show any one ever validated the axiom)?
Furthermore almost every one admits that existing concepts and definitions for
CBSE contradict reality we know about the physical components and CBD of
physical products.

Mankind already wasted 30 years by relying untested
axiom (i.e. myth) and willing to waste rest of their life by relying on the
myth rather than investigate the Truth and Reality. If this kind of flaw is
discovered in basic sciences such as physics or botany, wouldn’t it send a
shockwaves? Unfortunately software researchers justify this by saying computer
science is not a real science and yet they consider them selves scientists and researchers.

How can they consider themselves scientists and engineers,
if they insist computer science is not real science and software engineering is
not real engineering? If computer science is real science, can they rely on
untested myth (by insisting that it is self-evident fact that needs no
validation)? Don’t they need to have an
irrefutable proof for the basic facts on which they have been relying for
advancement of knowledge? If the basic fact on which they have been relying is
flawed, isn’t every concept derived most likely be flawed?

They made up their mind and not open to rational
reason or investigating Reality. This is how members of any cult behave. Not only they are wasting their time by
relying on untested myth, they are teaching the myth (as if it is self-evident
Truth) to brainwash impressionable students to expand the cult. If one ready to
accept software is not real science/engineering rather than investigate Truth,
how can he consider himself a scientist/researcher?

Wednesday, October 21, 2015

It reminds me Will Smith’s dialogue in iRobot (smartest
dumb person), when an expert refuses to verify simple fact that contradicts his
paradoxical paradigm, where the fact is otherwise simple and obvious to even a
layman.

How can any one say some thing is impossible without
ever even trying or even knowing what it is? No software researcher knows the
answer to a simple question (i.e. what is CBD) and yet blindly insists that it
is impossible, without ever even trying to know what it is (that he is
insisting is impossible). How could any one conclude that it is impossible
without ever even trying?

The question is: What is meant by the CBD (Component
Based Design) for the large physical products? That is, what is the true
essence of the CBD? For example, what are the striking aspects or
characteristics uniquely and universally shared by each and every known CBD (Component
Based Design) of large physical products?

In other words, what are the striking aspects
universally shared not only by the designers of product models of mature
product families (e.g. automobiles) and countless models of crowded product
families (e.g. cell-phones), but also the designers of one-of-a-kind product
models such as an experimental spacecraft, prototype of next generation
jet-fighter or a new kind of fuel-cell or nuclear powered locomotive.

In software, we deal with 100s of product families
ranging from compilers, OSs, Word, Spreadsheets, Games, Browsers, RDBMS,
Hadoop, search engines, PDF and ERP etc. The design of most software products
is more like designing of one of a kind product such as an prototype of an
experimental jet-fighter rather than the design of a model in a crowded product
family such as cell-phone, where software (e.g. OS and apps) are used for
competitive differentiation but not the core components (e.g. DRAM, Screens or
Flash memory).

Even in mature and crowded product families such as
automobiles, the core components (e.g. engine or gear-box) are custom designed
for each model for competitive differentiation. A mature product family means,
first model of the product invented decades ago, while crowded product family
means, hundreds of new models belong to the product family is under design by
dozens of product makers each year.

Let me define “what is real CBD” (e.g. true essence
and striking aspects): Implementing about 90% of the features and functionality
in replaceable components (i.e. real functional components), where each
component can be disassembled to redesign it individually and test it outside
of the product. Once the component is made as best as it can be, it can be
re-assembled to make sure it fits perfectly and performs as expected.

Please kindly pay attention to 15 seconds bit
starting at 1 minute 55 seconds. Let me paraphrase the 15 seconds bit, as I
understood it: Essential purpose of the real component-based engineering is
ability to look, feel and test each component independently to optimize
individually for making each component “as best as it can be”. Periodically
bring the components together to build product for making sure that (a) each of
them fit perfectly and properly collaborating with other parts, and (b) all the
components are fulfilling their respective roles as intended for proper
operation of the container product.

Designer of no physical functional component needs to
deal with spaghetti code/design, because it can be disassembled for redesigning
to make it “as best as it can be” (e.g. refining little-by-little by finding
and fixing its shortcomings) and testing it individually. Designer of no
physical component needs to deal with spaghetti code, because he is never
forced to see even a single line of code implemented within any other part.
Each and every large physical product is free from spaghetti code, because 95%
of the features & functionality is implemented in such replaceable components,
which are free from spaghetti code.

Therefore, the striking aspect of the CBD of physical
products is – no spaghetti code/design – about 90% of the features and
functionality is implemented in replaceable components, where a replaceable
component means a component that can be disassembled for redesigning it
individually and re-assembled after testing in outside of the product.

Therefore, a real CBD for software can be defined as:
implementing over 90% of the features and functionality in replaceable
components (or real software components that are equivalent to the physical
functional components). How can we invent real software components that are
capable of achieving real CBD for software? One way is to discover the sticking
characteristics uniquely and universally shared by each and every known
physical functional component. Unfortunately every software researcher
insisting that it is impossible to achieve real CBSD by refusing to learn the
simple truth, which is otherwise obvious.

The software researchers have been pursuing fantasy
and goals that are impossible to achieve such as software-ICs, reusable or
standardized components for 50 years. Designers of no physical product achieved
the goal such as software-ICs, except computers and cell-phones because they
are using not the core components (e.g. CPU or DRAM) but the software (e.g. OS
and apps) for competitive differentiation. How do they imagine that it is
possible to build software by assembling COTS (Commercially off the Shelf)
components, when designers of no other physical product (where software can’t
be used for competitive differentiation) ever achieved such fantasy?

On the other hand, no large physical product failed
to achieve real CBD, where real CBD can be defined as, implementing over 90% of
the features and functionality in replaceable components. Either complexity or
uniqueness (e.g. such as one-of-a-kind prototype of a spaceship or a new kind
of experimental jet-fighter) can’t prevent the designers from achieving the
real CBD. Each replaceable component is free from spaghetti code, because it
can be disassembled to redesign individually and test it independently outside
of the product. Since 90% of the design/code is implemented in such components,
over 90% of the code/design is free from spaghetti code/design.

Many experts insist that it is impossible to achieve
real CBD for software, without ever even trying. In fact, no one even knows or
ever heard what real CBD is, but blindly insists that it is impossible. No one
ever tried to define what real CBD is or try to achieve real CBD for software.
If they tried, they would have achieved within a short time. If anyone
disagrees, I respectfully request him to show me proof, if any one ever even
tried to define what is meant by CBD for the physical products, for example,
what is the true essence and essential aspects uniquely and universally shared
by design of any known large physical product.

The DEMO pages in our website (e.g. www.pioneer-soft.com) demonstrates many
real-software-components and sample applications, if they want to see the proof
that it is possible to achieve real CBD for software. In fact, any one can
create real-software-components and hierarchies of replaceable components using
our GUI library. And yet many researchers refusing to verify the proof, by
insisting that it is impossible to achieve real CBD for software.

The software researchers erroneously concluded decades
ago that CBD is using reusable or standardized components and pursued wrong
goals such as software-ICs for many decades, but not seceded and will never succeed.
So they concluded that it is impossible to invent real CBD for software. Now
they are not only insisting that it is impossible to achieve real CBD but also
refusing to know the truth about the real CBD (i.e. accurate definition for
real CBD).

The well known and irrefutable fact is, for real CBD
(e.g. of the artificial kidney or an experimental spaceship), it is not
necessary that even a single functional component is reusable, standardized or
conforming to any so called component models attributed to so called software
components. Their own conformational bias is preventing them from seeing even
such simple facts, which are otherwise obvious to even the laymen.

Isn’t it a classic example for extremely smart expert
behaving like a dumb person? How can I get through him and make him validate
the truth – physical evidence. We can provide any help he needs to build
hierarchies of replaceable components (e.g. http://www.real-software-components.com/CBD/City_GIS.html)
on his own to experience the truth firsthand. I made this offer countless times
to hundreds of researchers.

Let me conclude this long post by quoting Galileo’s
famous letter to Kepler: "My dear
Kepler, I wish that we might laugh at the remarkable stupidity of the common
herd. What do you have to say about the principal philosophers of this academy
who are filled with the stubbornness of an asp and do not want to look at
either the planets, the moon or the telescope, even though I have freely and
deliberately offered them the opportunity a thousand times? Truly, just as the
asp stops its ears, so do these philosophers shut their eyes to the light of
truth."

I
can’t understand, why smartest and accomplished scientists and researchers even
in 20th century, behaving not much differently from the principle philosophers
(i.e. scientists were referred to as philosophers) in the dark ages.

Tuesday, July 28, 2015

Software
researchers and Scientists forgot a simple scientific fact/rule: In real
science, anything not proven is an assumption. When any scientific field is in infancy,
researchers have no choice but to make few educated assumptions (e.g. first principles).
The researchers and scientists rely on such assumptions for advancing makings knowledge.
Unfortunately the scientific progress side-tracks and derails (i.e. end up in
crisis sooner or later), if there are fundamental errors in the first principles
(or assumptions) at the root of the scientific field.

It is essential to document
the assumptions to avoid or minimize the harm caused by such first principles
that are fundamentally flawed. Unfortunately computer science and software engineering
has such fundamentally flawed assumptions at the root. It is not wrong to make
assumptions 50 years ago (when software engineering was in infancy) and rely on
such assumptions to advance our knowledge. But it is wrong and violation of
scientific process/principles to rely on such undocumented or unknown assumptions.

I am sure thousands of researchers
would have exposed such fundamentally flawed assumptions, if the assumptions at
the root of software engineering were documented. For example, there are many baseless
assumptions at the root of software engineering such as software components are
different or unique. and it is impossible to invent software components that
are equivalent to the physical functional components (by having essential
properties uniquely and universally shared by each and every known physical
functional component) for achieving real CBSD (CBD for software), where real
CBSD is equivalent to the CBD (Component Based Design) of one-of-a-kind
physical products (e.g. an experimental jet-fighter or prototype of a new kind
of spacecraft).

For example, 500 years ago it
was considered blasphemy to question validity of then undocumented assumption ‘the
Earth is static’. Mankind relied on this undocumented assumption for centuries
and created a complex paradoxical paradigm (i.e. altered perception of
reality), and over the period this assumption at the root and the paradoxical
paradigm deeply entrenched into the collective wisdom of mankind.

Today it is considered arrogant
and disrespectful to question the validity of the definitions for so called
software components and so called CBSD/CBSE. Mankind relied on such undocumented
fundamentally flawed assumption for half-a-century and created a complex
paradoxical paradigm (i.e. altered perception of reality), and over the period
this assumption at the root and the paradoxical paradigm deeply entrenched into
the collective wisdom of software researchers. Not documenting such untested assumptions
is tantamount to considering them to be inalienable laws of nature, which would
become impossible to question over time as they deeply entrenched into
collective conventional wisdom. It might be impossible to even imagine invalidating
such assumptions 50 years ago, but not documenting them is kind of like
assuming that no one can ever find flaw in such untested assumption in million
years.

Such untested assumptions must
be documented in the first chapter books on software components and CBSD/CBSE,
so that they will be always on the collective consciousness of students. Documenting
such assumptions allow researchers to either validate or invalidate each
assumption as and when mankind’s scientific advanced sufficiently. Since such
assumptions are not documented, persons like me have to endure insults and disdain
to even mention possible error. Is it really impossible to find real software
components (e.g. for achieving real CBSD) even in a million years. If it is not
impossible to invent such real software components, such assumptions must be
documented, so that, future generations have a fighting chance (without facing insults
and disdain) to invalidate such flawed assumption for putting the scientific
and technological progress on right tracks.

If mankind were to acknowledge
the possibility that, the Erath might be moving just like any other planets, I
am sure, many researchers would have discovered that the Sun must be at the centre.
After all, there are just 9 known planets including Moon (e.g. to test the hypothesis
by putting each planet at the centre). But it was inconceivable 500 years ago
the possibility that the Erath is moving around any other planet. I am sure anyone
can discover real software components within weeks, if they acknowledge
possible error and try to investigate truth. How complicated it is to discover
the essential properties uniquely and universally shared by each and every
known physical functional components? Based on my experience, it just takes couple
of weeks. Unfortunately discovering the truth is not real problem, but the
problem is questioning the validity of the flawed first principles (i.e.
assumptions) at the root, which is real cause for any software field to end up
in crisis. This struggle gave me unique perspective of why and how any scientific
field end up in crisis (and how exposing the errors lead to scientific
revolution by putting progress on right tracks).

Saturday, April 4, 2015

In real science,
anything not having proof (or not proven) is an assumption and such assumptions
must be documented before relying on them to create definitions/concepts. Progress
of any scientific discipline would be sidetracked into a wrong path and end up
in a crisis, if there are errors in basic assumptions and if researchers relied
on such erroneous assumptions for creating definitions or concepts and for advancing
any scientific filed by relying on such definitions or concepts. No meaningful
scientific progress is possible until the scientific progress is put on right
path by exposing errors in such basic assumptions.

Why CBSD (Component
Based Design) for software needs different and new description (i.e.
definitions and/or essential properties) for software components and CBSD? These
new and different description, properties, and concepts for so called software
components and CBD for software products are in clear contradiction to the
reality (i.e. facts, concepts and observations) we know about the physical
functional components and CBD of large physical products (having at least a
dozen physical functional components).

There exists no
proof to show that any effort was ever made to discover reality about the
physical functional component and CBD of physical products before creating the
definitions and concepts for so called software components and concepts. The
definitions and concepts at the root of existing CBSD (Component Based Design
for Software) were made up out of thin air, without documenting the reasons or
first principles (i.e. assumptions) that compelled to create such definitions
and concepts that are in contradiction to the reality.

When I inquired for
reasons, I heard many unsubstantiated assumptions, such as software is
unique/different and/or it is impossible to invent real-software-components
that are equivalent to the physical functional components (by discovering
accurate description for the physical functional components and inventing real
software components that satisfy the accurate description). In real science,
anything not proven is an assumption and such assumptions must be documented
before relying on them to create definitions/concepts. No text book for
introducing software component or CBSE/CBSD listed such assumptions. No
research paper or publication listed such assumption at the root of existing
CBSD paradigm, which has been evolving for nearly 45 years by relying on such
unsubstantiated definitions and concepts made out of thin air..

When any scientific
discipline was in infancy, researchers are forced to make assumptions. For
example, assumption "the Earth is flat" was a reasonable assumption 4
to 5 thousand years ago. Likewise, the assumption "the Earth is
static" was a reasonable assumption 2000 years ago. But documenting such
assumptions would avoid huge pain and suffering such as: http://real-software-components.com/forum_blogs/BriefSummaryOfTruths.html#Chronology.
It is not hard to prove that, if the error at the root of geocentric model was
not yet exposed, no meaningful scientific progress would have possible during
past 500 years. As science and our knowledge expends, we can create tools to
validate such assumptions, if they are documented and well-known.

All I am saying is,
it is not wrong to make assumptions but it is wrong to not-knowing and
forgetting (e.g. by not documenting) the assumptions at the root of our
scientific knowledge, such as concepts and definitions for software
components/CBSD. In real science, any thing that can’t be proved is an
assumption. It is an error to rely on any such unproven assumption (without
clearly documenting the assumptions) to derive concepts or definitions.

For discussion
sake, let’s assume that the basic assumption was: “it is impossible to discover
a set of essential properties uniquely and universally shared by each and every
large physical functional component for inventing equivalent software
components (having the essential properties)”.

This is highly
falsifiable first principle (i.e. basic assumption at the root of software
components and existing paradigm for CBSD), so it can be (and must be) proved
false, if this basic assumption is flawed.

Likewise, if the
assumption was: “it is impossible to invent a set of essential aspects uniquely
and universally shared by each and every CBD of large physical product for
achieving equivalent CBD for software products (having the essential aspects)”.

This is highly
falsifiable first principle (i.e. assumption), so it can be proved false, if it
is flawed. May be such assumptions could not be proved wrong (when such
assumption was made and relied up on) 50 years ago, but they could be proved
wrong when technology advances sufficiently for validating each such
assumptions in the future (if such undocumented assumptions are flawed).

All I am saying is,
it is wrong to NOT document such assumptions before relying on such assumptions
for making up definitions for so called software components (out of thin air
without any basic in reality, but based on wishful thinking). If there are
errors in such undocumented first principles (i.e. basic assumptions), they
sidetrack the scientific progress into a wrong path and scientific discipline
end up in paradox.

If such assumptions
were documented, I am sure 1000 researchers would have proved each of them
wrong in past 50 years. But toady no one even know the assumptions to prove
them wrong, if they are wrong. Such unsubstantiated assumptions were completely
disappeared from our collective consciousness to even question their validity
in light of technological and scientific advancements.

For example, this
kind of assumption (i.e. it is impossible to discover such essential properties
for the physical functional components) contradicts almost every thing mankind
knows today. Let me define a universal rule: There exists an accurate
description (e.g. a set of essential properties) for every known kind of a
physical being or specie and the accurate description (e.g. a set of essential
properties) can be used to positively identify each specimen belong to the
being or specie. That is, the essential properties for any kind of physical
being or specie can be used to positively determine weather a given specimen
belongs to the physical being or specie.

Physical functional
components can’t be an exception to this universal rule, since it is impossible
to find any exception to this universal rule: It is possible to find an accurate description (e.g. essential
properties) for each and every kind of a physical being or specie.
Mankind’s scientific knowledge comprises accurate descriptions (e.g. essential
properties) for millions of physical beings or species. There are millions
examples to prove this universal rule, but impossible to find an exception to
this universal rule (e.g. to falsify this rule). Every scientific discipline
comprises accurate descriptions (e.g. often defined by a set of essential
properties) for physical beings or species (to positively identify each
specimen belong to respective kind of being or specie).

For example, isn’t
essential for the field of zoology to acquire and accumulate the knowledge of
accurate description for animals? Isn’t essential for the field of botany to
acquire and accumulate the knowledge of accurate description for plants? The
same is true for various sub-fields of microbiology such as virology, mycology,
parasitology, and bacteriology. Likewise, accumulating knowledge of accurate
description of atoms, molecules, compounds or elements is an essential for each
sub-field of chemistry such as organic, inorganic or bio chemistry. No proof
exists to show that the physical functional components are exception to this
universal rule. It is impossible to find any one ever even tried to prove that
the physical functional components are exception to this universal rule.

Once the set of
essential properties uniquely and universally shared by each and every physical
functional component is discovered, why is it not possible to invent equivalent
software components having the essential properties? Although we can’t
articulate the essential properties of the physical functional components, when
any physical functional component is shown, it is not hard for any expert to
positively identifying that it is a physical functional component. Likewise, it
is not hard for any expert to positively identifying that it is not a physical
functional component, if he is shown any other kind of physical part (that is
not physical functional component).

This expertise of
positively determine any given physical part whether it is a physical
functional component or not a physical functional component, can be leveraged
to discover essential properties uniquely and universally shared by each and
every large physical functional component. Once the essential properties are
discovered, it is a trivial task to invent real software components having the
essential properties for achieving real CBSD, where the real CBSD must share
the essential aspects uniquely and universally shared by each and every known
CBD of large physical product (having at least a dozen physical functional
components).

In fact, I can help
any engineering expert or researcher to discover the essential properties
uniquely and universally shared by each and every known large physical
functional component. Likewise, I can help any engineering expert or researcher
to discover the essential aspects uniquely and universally shared by CBD of any
physical product (having at least a dozen physical functional components). It
must not take more than couple of weeks to train any expert to gain this kind
of expertise for positively identifying multiple real software components
(equivalent to the physical functional components by having the essential
properties) in any software application for achieving real CBSD (equivalent to
the CBD of physical products by sharing the essential aspects).

Both teachers and
books teaching concepts and definitions of so called software components and CBSE
to impressionable students by forcing the students to learn definitions either
to pass the exams or solve problems using the definitions and concepts. Without
having proof, if it is right path or wrong path, we are pushing the
impressionable students to well traveled (but wrong) path. Instead of teaching
them (i.e. brain washing them),

We must ask
impressionable students to investigate truth, instead of brainwashing then and
pushing them into wrong path by teaching flawed definitions and concepts
(derived by relying on undocumented assumptions). Please kindly read this
interesting article, how reality can be distorted: https://www.psychologytoday.com/blog/pieces-mind/201208/few-the-many-ways-we-distort-reality.
One can find so many examples that show, how reality can be distorted and end
up in a paradox.

After graduation
and gaining 10 years hands on experience on so called software components and
CBSE (living in paradox of such distorted reality), obviously any CBSE expert
thinks I am crazy (arrogant or disrespectful) for saying reality/facts such as,
ideal CBD requires over 97% code must be implemented as CBD-structure (free
from spaghetti code), but it is not necessary that even a single large
component in the hierarchy need to have any properties we erroneously
attributed to so called software components.