Reality is immutable and never
changes. Duty of scientists is pursuit of absolute Truths for discovering the
reality (a set of Truths and laws of nature that are proven). Mankind’s perception
of reality changed many times. For example, several thousand years ago mankind
believed that the Earth is flat. Later 2000 years ago mankind believed that the
Earth is static. Until 500 years ago this flawed axiom (i.e. “The Earth is
static” considered self-evident truth) shaped our perception of reality (a
paradoxical paradigm), which was altered reality filled with retrograde motions
and epicycles.
Philosophers
had no problem accepting untested axiom (a Lie: the Earth is static) as
self-evident Truth (even though they have no evidence any one ever validated
it). But it had taken over 100 years to accept the Truth “the Sun is at the
centre”. This Truth faced huge resistance and undergone most rigorous validation.
Let
me introduce reality of CBD (Component Based Development) using a small
example. Mankind each year inventing and building 100s of new kind of products
around the world. For example, one example is trying to create artificial
kidney in this video: http://real-software-components.com/CBD/CBD_of_new_product.html.
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 design
is ability to look, feel & 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
properly collaborating with other parts, and (b) all the components are
fulfilling their respective roles as intended for proper operation of the
container product.
Please notice the reality of
CBD: There is no spaghetti code. Each component can be refined individually and
tested outside. Over 90% of the features and functionality is implemented in
such components. Any component can be refined and tested individually free from
spaghetti code. That is, without any need to see internal design or single line
of code of any other component. Hence over 90% of the design is free from
spaghetti code. Each component is custom designed to fit perfectly in just one product
model, so no component is reusable, standardized or conform to any of the so
called component models erroneously attributed to the software components.
Any true scientific fact,
concept or discovery must satisfy two conditions (1) it must not contradict the
reality we all know in the real world and (2) it can’t be falsified, while
being highly falsifiable. In light of these observations, let me define the
reality of ideal CBD (Component Based Design) for large physical products: The
reality of an ideal CBD for physical products is implementing over 90% of the
functionality and features in replaceable components, where each component can
be refined and tested individually (free from spaghetti code). The physical
product is evolved (or redesigned) by evolving (or redesigning) a set of
replaceable components.
Nether complexity nor
uniqueness (e.g. of a one of a kind product such as an experimental spacecraft or
prototype of a next generation jet-fighter) can prevent designers from
achieving 90% modularity. That is, the reality of CBS is implementing 90%
features and functionality in replaceable components, where each component is
free from spaghetti code (i.e. designer of any component never forced to see
even a single line of code implemented inside another component). It is not
necessary that even a single component in the product is replaceable,
standardized or conform to any so called component models (erroneously attributed
for software components).
Unfortunately the perception
of reality for software components and CBD for software has been shaped by
fundamentally flawed definitions and interpretation of the reality: When
Douglas McIlroy proposed building products by assembling COTS (Commercially off
the Shelf) parts as we build computers, it was just a proposal – a desire or
wishful thinking. It is not a scientific discovery (like the Sun at the
centre). There is no evidence any one ever tested its validity. But researchers
in late 1960s considered that it is a self-evident truth, and today software
researchers have been relying on this as if it is proven fact. Dr. Brad Cox
proposed software-ICs in 1980s.
Because of this altered
perception researchers completely lost their ability to even see obvious facts
and apply reason to discover the reality. It is nice to have software-ICs, but
is software-ICs possible or reality? Inventing cold fusion is nice, but can we
discover laws of nature that can make it reality? I don’t know about the cold
fusion, but I am sure that software-ICs as intended can never be a reality.
I requested many researchers to
investigate the reality. Is Software-ICs reality? Is it possible to achieve
Software-ICs for any other kind of physical product (e.g. automobiles or
Airplanes), where it is not possible to use software and applications for competitive
differentiation from competing products? The physical products such as cars
must use core components (e.g. engine, gear-box or powertrain) for competitive
differentiation from competing products.
For example, the makers or
cars, jet-fighters or other products custom design core components for
competitive differentiation. For example, even when they are relying on third
party component vendor for a component, they work closely with the component
vendor to custom design the part to perfectly fit juts one product model. For
example, Boeing works closely with Rolls Royce or Pratt and Whitney to build
custom engine. Likewise, Honda company works closely with makers of various
non-core components such as break-pads to custom build the break-pads (to
perfectly fit just one model). One can notice this kind of reality of CBD
everywhere all around us.
Software researchers argue
that software is unique, different and must undergo constantan changes. Why is
it any different from the above example for Artificial Kidney? They must also
constantly change each of the components until the whole product works. Only
difference is, they don’t have spaghetti code. That is, designer of any
component can refine and test his component individually, without being forced
to see even a single line of code implemented internally for any other
component.
Another reality is: The automobile
engineers just deal with many product models within just one product family
(automobile product family). Likewise, hardware engineers deals with many kinds
of product models within just on product family (i.e. families such as computer
or smart-phone). In software, we deal with hundreds of product families ranging
from compilers, OS, Video games to MS-Office. It is impossible to reuse core
components (e.g. engine or gear-box) for automobile product family can’t be
reused in any other product from another product family (e.g. PC or AC).
Likewise, core components for compiler product family can’t be used in any
other product from another product family such as Video games.
This kind of reality about the
CBD of physical products is everywhere all around us. All I am asking is to
investigate such simple and obvious facts to discover the reality. Isn’t is
obvious that it is impossible to achieve Software-ICs, where it is not possible
to use OS and applications for competitive differentiation? Can we invent COTS
that allow us to build new products (e.g. Artificial Kidney) that is not yet
invented? Is such COTS (e.g. Software-ICs) for not yet invented physical
products or that can be readily reusable across hundreds of families of
physical products?
Often, designing each new
software product is more like inventing a new physical product such as designing
one of a kind spacecraft. It is desirable to eliminate the spaghetti code,
because the features and functionality must be constantly changed until each of
the components and the whole product satisfies the unique and exact
requirements. Furthermore, this product must be changed many time in the future
to make each successive release. Over 90% of the cost, time and complexity can
be eliminated for making large changes by eliminating the spaghetti code.
What is the reason for spaghetti
code, even one need to satisfy unique and exact needs by iteratively changing each
of the parts little-by-little (e.g. see Artificial Kidney)? Nothing in the
reality of CBD for physical products can prevent software designers from
implementing 90% of the features and functionality is replaceable components
for achieving real CBD for software. Unfortunately every software expert
insists that it is impossible to achieve real CBD, without knowing what it is.
How can anyone insist
something is impossible, without knowing absolutely nothing and clueless about
it? It is impossible to find evidence that any one even ever tried to
investigate, what is the true essence of CBD for physical products, such as
what is the most useful and striking aspect that is uniquely and universally
shared by every known design of large CBD product in the world.
In other words, what are the
striking aspects that are unique to the CBD of physical products and
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. smart-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. It is
impossible to find any evidence that any one ever even tried to investigate for
answers to this question. But every one insists it is impossible to achieve
real CBD for software, without even knowing what it is. Also most of them
bluntly refusing to even know what it is.
I am sure, it is possible to
achieve the goal of implementing 90% of the features and functionality in
replaceable components for any software application. I am openly offering first
GUI library that allow anyone to create real software components for achieving
real CBD for software. The experience and insights gained while building GUI
applications by assembling real software components help software designers
discover the truth by experiencing reality. Also I believe, this reality will
be more useful than software-ICs, especially for building large software
applications.
How do we know and mankind
proved, the axiom “the Earth is static” is wrong and the axiom “the Sun is at
centre” is correct? Because the second axiom helped us to make subsequent
discoveries that include Universal gravity and Newton’s three laws of motion.
The three laws of Kepler and Universal gravity with the help of Calculus
allowed mankind to create a consistent mathematical model.
These and many other
unexpected discoveries (e.g. discovery of the Pluto due to inexplicable perturbations
in the orbit of Uranus) conclusively proved that our understanding of reality
is progressing on the right path. Of course, many other discoveries such as Theory
of relativity shaping our understanding of reality, which hopefully taking our
understanding closer and closer to the absolute Truth.
In software, we need to
discover reality to define the realistic goals. Achieving Software-ICs is not
realistic. On the other hand, it is impossible to find a valid reason why it is
not possible to achieve 90% modularity. Today not even 10% of the features and
functionality of any large software application is modularized as the way real
physical functional components modularize the design of that large physical
products.
Best Regards,
Raju Chiluvuri
