This is continuation to this previous blog dated 26th Nov, 2013. It
is useful to read up to the point where the previous blog refers “Cognitive
Dissonance”. Today “cognitive dissonance” for each SCC (i.e. component) builds
up as more and more spaghetti code is added for other SCCs in the application.
In case of real-CBD, componentization and hierarchy of components eliminates
such cognitive dissonance. That is, componentization (i.e. encapsulating each
SCC in a RCC) allows focusing on a given problem at hand (i.e. each of the
RSCCs in the component-hierarchy), without any overbearing interference and
huge distractive noise from surrounding issues (i.e. code sections for other
SCCs).
The CBD-structure(or hierarchy of replaceable
modules) is single most
essential aspect universally shared by each and every large physical CBD-product
(exists today or in the future). If I were designer of Hard Drive or Power
Supply of an experimental computer, how long would it take for me to find the
all the parts (i.e. devices) of such large container component for a making
minor redesign to the component or to replace the component? It would not take
more than few minutes to find the component for either replacing the component
or to redesign and test the component individually outside of the product.
Today the computer is designed as shown in FIG-2, as a hierarchy of replaceable
modules, where each component can be disassembled (or plugged-out) and
re-assembled (or plugged-in) in mater of minutes. But imagine if the computer
were designed as shown in FIG-3, where each device of a large
component (comprising hundreds of devices) is hard wired into the system-board
along with the devices for other such large components (comprising hundreds of
devices). The FIG-3 illustrates, how complex software having multiple SCCs is
being designed today. It is essential to keep in mind that even large
components (i.e. SCCs) by nature can be loosely coupled, while other kinds of
parts (even small parts) used for building large components by nature tightly
coupled.
Compare the cognitive dissonance for the components in a
CBD-structure with the cognitive dissonance of a large software component such
as City_ATC having 5,000 lines of code or container component such as City_Landmarks having 15,000 lines of code in a
medium size application having 500,000 lines of code. How long it would take for
me to find all the code-section for City_ATC that are spread across multiple
non-exclusive files after a gap of few months to redesign the component? Is it
practical to effectively remove all the code-section to effective remove the
component? What is the cognitive dissonance for a newly hired software engineer?
Compare the cognitive dissonance for above components
(i.e. City_ATC and City_Landmarks), if each
of the components is designed as a RCC and assembled into the application by
implementing 2 to 3 lines as illustrated in Listings-1 and Listings-2 (where the coupling interfaces and
communication code are respectively managed and created by an intelligent
CASE-tool).
The cognitive dissonance of each component represents
non-essential or accidental complexity wasted for making a small change to the
component. In his famous seminal paper "No Silver Bullet — Essence and
Accidents of Software Engineering" Dr. Brooks persuasively argued that
there is no ‘cognitive dissonance’ (i.e. accidental complexity) and/or not
possible to eliminate ‘cognitive dissonance’ (i.e. accidental complexity).
I respectively disagree based on the easily verifiable 3-CBD-facts. His
famous seminal paper and famous book “Mythical Man Month” has huge influence on
shaping software engineering research and our belief that software is
unique/different and all the complexity is essential (so not possible to
eliminate). This is true in the existing paradigm, which is build by relying on
a huge error that prevented us from discovering innate nature of
real-components.
However discovering unique essential characteristics
universally shared by the physical functional-components not only expose the
error but also help invent real-software-components equivalent to the physical
functional-components for achieving real-CBD (e.g. CBD-structure) for
eliminating cognitive dissonance for each of the components in the
component-hierarchy. I always admire and still a big fan of Dr. Brooks, but I
have to respectfully disagree with him now (based on my recent discoveries).
Few years back in his email response to me, he said that
reasonable people can disagree. Unfortunately I have to even disagree with that
statement, since in the context of basic science there can be only one accurate
answer for nature of physical beings (e.g. diverse spices of components or
animals) or physical phenomenon (e.g. CBD or controlled powered flight). The
laws of nature are immutable and they can’t be changed or defined by a
committee (as we have been doing by defining many kinds of so called software
components & CBSDs).
Can respected scientists disagree, if the Earth or the Sun
at the center, without any scientific basic and factual support. Can the
scientist debate or disagree on Newton
Of course, respected scientists still could say that all
this is just a theory, so there still could be flaw. But I don’t know what kind
of excuse possible, when I can show practical results by demonstrating
countless applications created as hierarchy of replaceable components on my
laptop? I created hundreds of applications as hierarchy of replaceable
components, when I accidentally discovered replaceable components more than a
decade ago, which induced irresistible curiosity that driven me to focus on this
long and arduous research.
