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
laws of motion, without any scientific basic and factual support? Therefore, I
believe that the scientific process is broken in the computer science and that
must be fixed: http://real-software-components.blogspot.in/2013/11/the-process-of-scientific-research-is.html. 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.