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.
Every year mankind is trying to invent and design
100s of new kinds of physical products. Kindly allow me to give a simple
example for real CBD. Please watch this short 3 minute video either at: http://www.real-software-components.com/CBD/CBD_of_new_product.html
or at you tube https://www.youtube.com/watch?v=hc5e5cYdshI
– This shows the reality of CBD of physical products, where no core component
is reusable or standardized.
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.
Best Regards,
Raju
