Those who fail to learn from history (or ignorant of history) are doomed to repeat it

All great truths begin as blasphemies. - by George Bernard Shaw

Please kindly visit this web page to see chronology of contentious and controversial events for the discovery of one of the greatest scientific Truths: http://real-software-components.com/forum_blogs/BriefSummaryOfTruths.html#Chronology

Please kindly visit this web page to grasp the true essence of the CBD of physical components (that is to eliminate spaghetti code): http://real-software-components.com/forum_blogs/FirstPrinciples-FalsifiableFacts.html

Can any one find a valid reason why it is not possible for software applications to contain “hierarchies of replaceable components” (to eliminate the spaghetti code)?

                 

We can demonstrate hundreds of “hierarchies of replaceable components” for GUI-applications (having 0% spaghetti code). Today it is impossible to find even a single software application having such “hierarchies of replaceable components”. Today it is impossible to find even a single large replaceable component having few dozen GUI-components such as charts, buttons and lists.

Exposing scientific Truth (that exposes flaws in any prevailing deeply entrenched paradigm) is a complex and noble endeavor.

A simple and irrefutable fact is, existing definitions for software components are erroneous and insidiously flawed. This huge error can be exposed by discovering the truth, such as essential characteristics uniquely and universally shared by every known physical functional component and essential aspects of CBD (Component-Based Design) of complex physical products. There exists a truth and the truth can be discovered. It is an irrefutable scientific fact that, there exists an accurately description (e.g. A set of essential characteristics) for any kind physical being (including physical functional components) and the truth (i.e. the accurate description) can be discovered. The scientific or research community never made any effort to discover the Truth.

The truth is, every known physical functional component shares two essential characteristics and any physical part can be a component if and only if the part has these two essential characteristics. It is possible to discover the essential properties uniquely universally shared by the physical functional component. One of the main objectives of our website is to help experts discover (i) the essential characteristics uniquely universally shared by the physical functional component, and (ii) essential aspects of CBD (Component-Based Design) of the physical products.

Another important fact is, no other kind of physical parts except components can achieve such real CBD (having the essential aspects). It is possible to invent or create equivalent software components (by having the essential properties). Therefore logically no other kind of software part (without having the essential properties) can be a component, and no other kind part can achieve real CBD for software.

Until 500 years ago mankind believed that the Earth is static at the center. Now we know that it was wrong, because we later accepted the fact that the Sun is at the center of our planetary system. However, 500 years ago, it was not easy to prove that the axiomatic assumption (i.e. Earth is static at the center) is erroneous, since geocentric paradigm had been evolving for over 1000 years and countless epicycles and retrograde motions were well documented to justify the geocentric model. Any one living on the Earth all his life had no evidence that the Earth is moving and had no problem observing retrograde motion. Besides there were no simple answers to questions such as, if the Earth is moving, why the Moon is not left behind?

It took more than 100 years and great sacrifices to expose the error in the seed axioms of then deeply entrenched geocentric paradigm and conventional wisdom. Telling the Truth (i.e. the Sun is at the center) offended then deeply entrenched conventional wisdom and common sense. The Truth was exposed at great sacrifices, for example, Galileo was impression for life and Giordano Bruno was killed for advocating the Truth.

Even in the 21^st century, many respected scientists and researchers feel offended, if I say that the existing definitions for so called software components are fundamentally flawed. Many software experts feel that, I am insulting the common sense and refuse to learn the facts that can expose the Truth. The researchers and scientists have been using every possible excuse to evade their sacred duty of discover truth.  When confronted in an open forum, they have been using silly and baseless excuses to ignore the inconvenient facts and reasoning.

Most experts demand that proof must be in few sentences. It was not easy 500 years ago to prove that the Sun is at the center. It was not easy to expose errors in seed axioms of any deeply entrenched paradigm. I respectfully request researchers to discover the truth about physical functional components and CBD of complex one of a kind physical product. It is their sacred duty to discover the Truth to over come myths and insidious epicycles that have been accumulating in any deeply entrenched paradoxical paradigm (which has been evolving for decades or centuries) in the name of scientific progress, which results in alerted reality.

How is it possible to provide proof in few sentences to overcome this kind of altered reality (supported by thousands of myths and epicycles accumulated over decades)? Out website can only help scientists discover truth, only if they are willing to discover the truth with open mind.There exists a Truth about real-components for achieving real-CBD, and the Truth can be discovered.

The existing software engineering paradigm have been evolving by relying on unsubstantiated myths such as any kind of software parts (either having certain useful properties or conform to so called component model) is a kind of software components. It has no basis in reality. Using such fake components is not CBSE. Our website has irrefutable proof for the scientific fact: No physical part can be a component without being (i) replaceable and (ii) self-contained. It is absolutely essential to rely on the knowledge of error free scientific facts, reality and sound logical reasoning to transform computer science into real science and software engineering into a real engineering.

Many experts insist that, it (not inventing real software components) is not a big error – We respectfully disagree. If physical components and CBD for physical products offers only very little benefits in designing and building complex physical products, then not having real-software components is a minor error. But it is a huge error, because it is practically impossible to design and build complex physical products. The flawed definitions for so called software components preventing the research necessary to discover the nature of physical functional component for inventing equivalent software components that are capable of achieving real CBSD.

           It is not a small error to rely on flawed facts (and resulting paradoxical reality) for advancing any scientific field. Mankind still would be in dark ages, if the so called small error (the Earth is at the center) were not yet exposed. More than 500 years ago, even the basic science end up in a paradox (i.e. as a fake science), and exposing the error eventually resulted in transforming it into a real science. Only possible path available for scientific progress is discovering and relying on truths (i.e. fact and reality). Scientific progress is impossible, if researchers and scientists try to advance any science field by relying on flawed facts (and applying brute force to advance the field for prolonged period only leads to altered reality).

Any scientific field ends up in altered reality (e.g. paradox) and as a fake science, if basic facts the researchers have been relying to advance the field has hidden flaws and researchers apply brute force to advance the field without realizing the flaws. Software engineering ended up in an altered reality due to the brute force being applied since mid 1960s to advance software engineering, without ever validating the definitions for so called software components exist today.  Whenever I try to expose flaws in the existing software engineering paradigm, today software researchers justifying the paradox (i.e. altered reality) by using silly excuses such as computer science is different. No meaningful progress is possible until the truth (i.e. reality and facts about physical functional components & CBD of physical products) is discovered, even if it is hard to discover the Truth.

How can I expose huge errors in seed axioms of computer science and resultant software engineering paradigm?

Please kindly understand why I am having trouble in exposing these huge errors in seed axioms of a complex deeply entrenched paradigm. Since exposing the error in the seed axioms of geocentric-paradigm 400 years ago, I can’t find another example where scientists made such huge error in basic axioms and depended on the erroneous untested axioms (by assuming that the erroneous untested axioms are facts) for nearly half a century for advancing a very popular field such as software engineering.

Untested axioms (having errors) but are considered to be facts:

1.    Each kind of software part or module either having certain characteristics (e.g. reusable or standardized etc.) or conform to a so called component model is defined as a kind of a software component.

2.    Using one or more kinds of such so called software components is defined as a kind of CBD for software.

Let me get to the root of the problem. Every useful engineering concept and invention (i.e. engineering, chemical, pharmaceutical, medical, biotechnology or biological inventions) known to mankind is rooted in scientific facts. The knowledge of scientific facts forms the foundation to the inventions and concepts of engineering and applied sciences. Each engineering invention or concept is derived from a set of facts (i.e. selected from a large base of scientific knowledge) by applying sound reasoning and logic. No such invention could work and any engineering concept ends up in crisis (and flawed), if there are errors in any one of the facts and reasoning or logic.

Every engineering invention and concept is rooted in proven facts and derived by using reasoning and logic. It is impossible to find an exception to this rule in any other engineering discipline, except the definitions for nature and characteristics of the so called software components. These untested axioms (i.e. definitions for so called software components) are made from thin air, without any basis in reality or facts (e.g. by ignoring all the reality and obvious facts known to mankind about the physical functional components). Only basis for the axioms is desire and fantasy of building software by assembling reusable components (as mankind has been building computers). Please review few paragraphs, if you like to see couple of sample invention derived from scientific facts: http://real-software-components.com/forum_blogs/BasicScientificPrinciples.html

In case basic science (e.g. botany, zoology or chemistry) the scientist accumulate the scientific facts. The researchers of applied sciences or engineering rely on the knowledge of the facts and apply reasoning and logic to derive concepts for applied sciences (e.g. engineering, biotech, medical or pharmaceutical fields) to make useful inventions. Few exceptions to this rule are discovery of penicillin or X-ray, which are invented accidentally and applied reasoning and logic to discover scientific facts. These scientific facts helped invent many other kinds of antibiotics or X-ray machines. But ultimately all the concepts and inventions are rooted in the scientific facts.

You may skip this evidence, but it is possible to prove that the axioms are just science fiction: http://real-software-components.com/CBD/main-differences.html AND http://real-software-components.com/RSCC/ecosystem-evolution.html

Please kindly assume this: It is possible to discover essential properties or characteristics uniquely and universally shared by each and every known physical functional component; and also assume that the essential characteristics are {C7, C9}. Please let me define, what an essential character is: No physical part can be a component without having the essential character and the component can no longer be a component, as soon as it looses the essential character (or property).

If such essential characteristics exist for physical functional components and if it is possible to invent equivalent software component (by having the essential characteristics), logic dictates that no other kind of software parts (or modules) can be software component. It is possible to validate the facts and logic for inventing real software components using many other independent ways.

For example, the following is one of many ways to independently validate the facts and reasoning or logic used for inventing real software components: If it is possible to discover essential aspects of uniquely and universally shared by CBD of physical products and the essential aspects are {A3, A6}. If such essential aspects exist for CBD of physical products, logic dictates that the using real software components must result in equivalent CBD for software products (or CBSD), where the real CBSD must shares the essential aspects {A3, A6}.

I discovered such essential characteristics {C7, C9} for physical functional components for inventing real software components that are capable of achieving real CBD (having {A3, A6}) for software products.

The discovery that ‘the Sun is at the center’ implied no other planet can be at the center, which exposed the error in then deeply entrenched axiom ‘the Earth is at the center”. Likewise, this discovery of essential properties implies that no other kind of software parts without having the essential properties {C7, C9}, can be a real component for software (and using such fake software components can never achieve real CBD for software products). Furthermore, discovering the essential aspects of physical phenomenon CBD for physical products to make sure the real software components achieve a CBD for software (i.e. sharing aspect A3 and a6), which is equivalent to the CBD for physical products.

If the above seed axioms for software engineering are not made out of thin air, kindly provide the scientific facts and reasoning or logic used for deriving the axioms. Please forgive me, if the following facts appear arrogant or disrespectful:

The researchers of software engineering wasted billions of dollars and few decades of passionate research by relying on those untested axioms (by erroneously concluding that the axioms are facts). This passionate research (i.e. brute force) spanning many decades for advancing software engineering resulting in a complex paradigm and altered reality (i.e. a paradox). Today software engineering researchers are unable to come out of the paradox and lost their ability to see reality about ideal CBD of physical products and nature of ideal physical functional components.

These erroneous concepts are being taught to impressionable students in class rooms resulting in indoctrinating each new generation in to the paradox (or cult) and later years of experience of using so called software components and CBSE permanently altered the perception of experts (preventing them from seeing of reality). Establishing a new theory is tough; making changes in an existing theory is tougher, particularly when the changes are suggested in a field that had originated nearly half a century ago, and hundreds of books and thousands of articles have meanwhile been published in that field the world over.

I discovered that the essential characteristics for ideal physical functional components are (i) Replaceability (i.e. the component can be disassembled as a unit by removing 3 to 5 lines and re-assembled by implementing by removing 3 to 5 lines) and (ii) Self-contained. So this component is also referred to as RSCC (Replaceable Self Contained Component).

The ability to positively identify is a tacit knowledge that can be and must be acquired: It requires few weeks for analyzing hundreds of functional components in light of equivalent software components for discovering intended meaning of the term ‘Self-contained’ with respect to software (and for acquiring necessary tacit knowledge and tacit expertise for positively identifying multiple SCCs in each large software application).  But in brief, a RSCC is a component custom designed for just one target application, so that the component doesn’t require any more construction or configuration code (i.e. it should require no more than 2 to 3 lines to assemble the component, and removing the 2 to 3 lines must effectively remove the component without leaving any more traces of code associated with the SCC (where the associated code includes communication code or code for getting any data to construct or configure the replaceable component).

Today any large custom application requires implementing tens of thousands to hundreds of thousands (or even millions) of lines of custom application code, even after using all the tools and libraries. Each of these applications comprises multiple ‘Self-contained’ components (or SCCs). When it is impossible to reduce the custom application code (e.g. by using any other kinds of tools or library), the real CBD for software recommends identifying multiple SCCs in the application and implementing the application code of each SCC as RCC (Replaceable Component Class) to make the SCC a RSCC.

Please kindly allow me to illustrate a sample application that is built by assembling real-software-components and achieved real CBD for software: http://real-software-components.com/CBD/City_GIS.html

This sample City_GIS application has just 6 large components, where no component requires more than 3 lines to assemble. In this application, no component requires implementing any more communication code, because each component implements necessary communication code to use the intelligent CASE tool to collaborate with other components and parts of the application: You may find a sample  intelligent CASE tool in FIG-3 at: http://real-software-components.com/CBD/Sample_SoA_CASE_tool.html

Today code base (i.e. all code sections) of almost no large ‘Self-contained’ part (or SCC) is implemented as RCC (Replaceable Component Class) by conscious design effort. That is, the RCC is a new kind of component, so designers must put conscious effort to identify the SCCs in the application. Our CBSD requires identifying multiple SCCs and implement each SCC as a RCC.

If all the SCCs are identified, over 97% of the application code can be implemented in one of the RCCs. In that case, if an application has 200 SCCs and 200 RCCs are implemented (by designing and testing each RCC independently), the application can be built by assembling all the 200 components within few hours.

If the average size of the RCCs is 2500 lines, then total size of the custom application code is 500,000 lines (200*2500). Today this 500K lines end up as spaghetti code (even in case of most optimal design), in multiple non-exclusive files, where the non-exclusive files contains code-sections for more than on SCC. In case of our CBD, these 500K end up in 200 RCCs, where each RCC can be redesigned and tested individually (at any time in the future to add more features, for example, to release future versions of the software application).

Today both cases (existing paradigm and proposed paradigm), requires implementing 500K lines (if code base can be highly optimized). In our case, each SCC/RCC is designed and tested individually as an independent application, so code base end up in exclusive files (i.e. no file contains code for any other part of the application). It requires far less effort to re-factor code base of each RCC to make the overall design optimal. In case of existing paradigm, in reality it is not practical to optimize the code base of the application, so the code for the application could end up 600K+.

I have been passionately doing research on the nature of functional components and CBSD for more than 12 years, after accidentally discovering RCCs and creating 100s of replaceable components and hierarchy of replaceable components (during 1999 and 2002). So I can justify each and every aspect or statement.

Dr. Brooks predictions and laws hold for another 1000 years, if it takes 1000 years to expose this error in seed axioms. The error might appear very small, but it is a huge error and no meaningful progress is possible until this error is exposed. For example, 500 ago no one realized the implications of exposing the error in the seed axioms of geocentric-paradigm. Many philosophers even argued that it would have little or no effect on the advancement of scientific fields.

We can find irrefutable proof that, an error in seed axioms always sidetracks scientific progress. Exposing the errors in the seed axioms puts the progress on the right track and often its implications would be apparent when next great discovery is made by traveling on the right tracks. For example, it was impossible to discover Gravity or Newton’s laws of motion without putting the scientific progress on the right tracks by exposing the erroneous seed axiom for geocentric-paradigm.

It would not be hard to predict the future of basic sciences for 16th century philosophers, if the error in seed axiom “the Earth is static at the center” were not exposed until now. But how could they predict future or “E=M*C-Squared”, fusion bombs, gravity, computers, fiber optic networks, cell-phones and quantum mechanics? Software engineering has been stuck in the rut of spaghetti code and not going anywhere for nearly three decades. It will continue to be stuck in the rut until the errors in the seed axioms are exposed.

It is impossible to invent real CBD for software products without inventing real software components. It is impossible to invent real software components without discovering scientific facts such as the nature and essential properties of the physical functional components and nature and essential aspects of the CBD for physical products. The CBSE researchers must acquire this kind scientific knowledge and then apply sound reasoning and/or logic for (i) inventing “real components for software” and (ii) deriving concepts for “real CBD for software”.

I request researchers to kindly provide the scientific facts and reasoning and/or logic used for deriving the above seed axioms of software engineering, If the axioms are not made out of thin air?

Is any such useful concept or invention (e.g. in any discipline of applied science such as engineering, chemical, pharmaceutical, medical or biotechnology) during past 150 years made out of thin air? Is it possible to find any useful engineering concept or invention created by mankind that is not rooted in a set of scientific facts or derived by applying flawed reasoning and logic by relying on the facts?

The essential nature or purpose of ideal components is superior plug-in/unplug modularity

          Today software engineers could leverage huge infrastructure comprising tools, compilers, RDBMS and reusable libraries for building software applications. Even after using all kinds of available libraries and tools from the mature infrastructure, today many large applications still require implementing millions of lines of custom application code. It is impossible to avoid implementing custom application code, so it is designable to modularize the custom application code into replaceable components (which can be unplugged by deleting 3 to 5 lines of code and plugged-in by implementing 3 to 5 lines of code), which must achieve highest possible modularization by eliminating all the reasons that cause spaghetti code (e.g. to effectively disassemble, re-assemble after redesigning or to replace):   

My Research Goal is to invent a new kind of software components that can achieve a new kind of CBSD (Component-Based Design for Software Products). The characteristics of the replaceable components are (i) no component must require more than 3 to 5 lines of code to plug-in the component as a unit, (ii) must encapsulate few hundred lines to few thousand lines of application code and (iii) removing the said 3 to 5 lines of code must effectively remove the component as a unit (leaving no traces of any associated application code). These new kind of components are referred to ‘replaceable components”, since any component can be removed by removing 3 to 5 lines and replaced by another equivalent component by implementing 3 to 5 lines of code.

            If an application needs implementing 200K lines of application specific code and if I am responsible to implement 20K lines of code. Why should I be forced see even single line of other code implemented for the application (where the other code was not implemented by me). Excerpt the code I am responsible for implementing, I wish, I must not be forced to see even a single line of code by other developers against my will or choice.

            Likewise, excerpt the code he is responsible for implementing, no other developer writing code for the application must be forced to see my code or code implemented by any other developers against his will or choice. Each developer should be able to design, develop and test his components to make each of his components as best as it can be (before plug-in each of his components in the application for further testing). He should be able to use SCCS (Source Code Control System) to version each of his components.

            To implement my 20K lines, I need to start implementing one line at at time. I must be allowed to focus on just my code, without any interference or noise such as forcing me to see other code implemented for the application, which is the application code not implemented by me on which I have no control or want any control.

This must be true for all the developers, whenever any developer need to redesign his/her components any time in the future throughout the evolutionary life-cycles of the component and the product that is using the custom component. Each developer should be able to checkout the source code for any component from the SCCS and redesign it for creating an improved version or to offer more than one version to offer a choice.

Although we in software may think this kind of components are revolutionary, illusions or fantasies, the designers of complex one-of-a-kind physical products (e.g. prototype of a spacecraft or experimental Jet-fighters) take this kind of components for granted and don’t even notice to appreciate what they have (which are consider science fiction by many scientists of computer science or researchers of software researchers).

Today me or any other developers is forced to add his code-sections (often implemented one line at a time) to multiple non-exclusive application files, where more than one developers are forced to add his code-sections (often implemented one line at a time) to the non-exclusive application files. This creates unnecessary interference and complexity leading to spaghetti code, since each developers often need to revisit the code-sections in non-exclusive files to fix or to optimize the features as he gains more and more insights into the application design and user needs (as he has been coding one line at a time to implement more and more code and thinking each and every day).

The structure of the spaghetti code implemented in non-exclusive files progressively degrades as each of the components is redesigned for future releases in the normal evolutionary life-cycles of each of the components and the product comprising all the components.

The reality is, many developers would leave the product development and new developers join to replace the product development. The writing style and thinking of any two English writers hardly matches: http://bits.blogs.nytimes.com/2012/01/03/software-helps-identify-anonymous-writers-or-helps-them-stay-that-way/?_php=true&_type=blogs&_r=0. How can we expect two junior developers would think alike (especially under the stresses of release datelines and girlfriend problems)?

For example, I created few components for an application for KLA-Tencor in 1994 and I was proud of my design (maximized exclusive files). I took a long vacation, nearly 4 months and another developer was asked to add few features to my code for an intermediate release. After returning, my boss told me that the other developer complained that my code and style was very hard to understand. I implemented 2 to 3 entry points and 3 to 4 exit points (I don’t remember correct number). To add few features, he changed the structure of the code, which I had hard time understanding, when I took back control over the code. He changed the structure and unnecessarily added interfaces to entry and exit points (instead of changing the existing interfaces).

I am sure, any designer could identify many SCM (Self-Contained Modules) in any large software application, once the essential characteristics of ideal physical functional components are discovered, and where the essential characteristics are characteristics uniquely and universally shared by each and every known large physical functional component exist today.

Any harm could fell upon computer science, if scientists and researchers of computer science discover facts (i.e. the essential characteristics). I never heard of any truth that harmed any field of science. My understanding of ideal functional components is modularization. No other kind of physical part can match the modularity of physical components. All I am requesting research community to discover the hidden nature or characteristics that are allowing the physical components to achieve such superior plug-in/unplug modularity.

It is not necessary that even a single component in the hierarchy of replaceable components (i.e. CBD-structure) posses any of the characteristics (e.g. reuse or standardization) erroneously attributed to so called software components known today. Inventing more kinds of reusable modules to minimize the required application code is a noble goal. But my goal is not in conflict with such goals, as clearly stated in the first paragraph. For example, each component for City_GIS is custom designed to satisfy just one target application.

Other software component researchers were working on increasing the degree of modularity. To them, I request to remember, no other kind of (either software or physical) module could match the modularity of the physical components. Only difference is, the designers of physical products have them and we still need to invent them (by discovering the essential characteristics).

Nothing strengthens a truth or once faith, more than then being rigorously tested. Many experts convinced that I was wrong or even crazy to say: It is an error to blindly define/dictate nature or essential characteristics without any basis and reality. Fortunately I created hundreds of real-components and component hierarchies between late 1998 and 2003 (I only worked part-time). I could fall back on them and create few more to reassure myself that I am not crazy. Irresistible curiosity forced me to focus full-time on this research since 2003.

My faith in this discovery has been well tested and I am more confident than ever. If I am wrong, no one could be bigger looser than me, because I invested more than 12 years of my most productive life and spent lot of money on securing US patents on essential characteristics of real components, enabling tools such as GUI-API and intelligent CASE-tools.

The biggest fear to me is not loosing the time and money, but some one else finding a real error (that I might have missed), which can prove to me that I am really crazy (death probable better than such humiliation), because I disputed and disagreed foolishly with respected experts of our field. I had many nightmares about such possibility and woke me up in the middle of night. I had to spend few days to re-assure myself. That is the reason, I am only asking the researchers to just discover the truth, if they agree with scientific process: Relying on erroneous facts (by not knowing the truth) to advance technology could cause irreparable damage to the technological progress: http://real-software-components.com/forum_blogs/BasicScientificPrinciples.html

All I am requesting is, please invest few weeks of your valuable time to discover the essential characteristics. Based on my decade of passionate research, I believe it will be well worth the investment or risk (even if some researchers feel it is a risk).

Best Regards,

Raju Chiluvuri

Couple of Basic Differences Between real-software-components and other kinds of so called software components

What is orange Juice? Any kind of juice extracted form Orange fruits. No other kind of juice extracted form any other kind of vegetable (e.g. carat, potato or brinjal) or forest fruit (tomato, dewberry or palm) can be Orange Juice. It is foolish to blindly define juice extracted from potato is a kind of Orange Juice, define juice extracted from tomato is another kind of Orange Juice and juice extracted from dewberry is yet another kind of Orange juice (without ever trying to discover “what is an Orange fruit”).

What is CBD (Component-Based Design)? Any kind of product design that uses components for building a product is CBD. Obviously using fake components can never be CBD, so it is absolutely essential to make sure that the components are not fake, by discovering “what is a component”.

The components are very special kind of parts having very unique and essential characteristics. That is each and every real component uniquely and universally shares certain characteristics. No other kind of part can be a component. No other kind of design can be CBD. That is, using any other kind of part can't be CBD. Hence, it is error to define any other kind of useful parts (either having certain useful properties or conform to a so called component model) is a kind of software components and it is error to define that using any kind of such so called software components is a kind of CBD for software.

Important conditions for real-CBD: (1) Cost of disassembling or reassembling must be less than 3% of the total cost of designing the product as hierarchy of replaceable components (i.e. CBD-structure), and designing and building all the components. (2) Each of the components in the CBD-structure can be redesigned and tested individually either in step-1 or step-3 of CBD-process.

In case of software, any real component must be self-contained and can be redesigned and tested individually without touching or even seeing a single line of code implemented for any other component. For example, reusable modules such as each reusable-class for a GUI-component (e.g. line-chart, pie-chart or bar-chart) can be redesigned and tested individually without touching or even seeing a single line of code implemented for any other component. But such classes can neither achieve the 1^st condition nor can be replaceable-components. Furthermore, each reusable class is not self-contained, since it requires implementing substantial application logic (e.g. to access and process application data for using the data to construct and configure a singleton object instance of a reusable-class) in order to preset a singleton self-contained component (or SCC). Also the resultant SCC is not replaceable (i.e. can’t be disassembled as a unit), since it requires removing all this spaghetti application logic to effectively remove even such singleton self-contained component.

But each of the RSCC (replaceable self-contained component) in the CBD-structure could be more complex as illustrated in City_GIS application. For example, components such as City_ATC or City_Theaters comprise dozens of GUI-components, where each GUI-component is presented by implementing necessary application logic to access/process application data for using the data for initializing and configuring an object instance of respective GUI-classes. The application logic implemented for including each of the GUI-components in a container-RCC (Replaceable Component-Class) for presenting in container-RSCC is generally implemented as a spaghetti code, so no single GUI-component is replaceable individually (i.e. can’t be disassembled as a unit to redesign and test individually, since it requires removing all the associated application logic for effectively removing each of the GUI-components).

Let me define two-kinds of self-contained components (SCCs) (1) singleton-SCC, and (2) compound-SCC, where application code for singleton-SCC uses only one object-instance of a large reusable GUI-class (e.g. for a Pie-chart, Line-chart or a reusable-class for a container GUI-component containing multiple sub-GUI-components) and implements necessary application code for including a SCC, while compound-SCC uses multiple reusable GUI-classes for instantiating multiple object-instances and implements necessary application code for initializing/constructing and configuring each of the object-instances to present multiple GUI-components in a SCC (e.g. City_ATC or City_LandMarks).

Our CBD requires partitioning or identifying SCC in an application and encapsulate all the application code that must be implemented in a RCC (Replaceable Component-Class), so that the SCC can be plugged-in by writing about 3 lines of code (without any need for any additional spaghetti code) and the SCC can be unplugged as a unit (without leaving any traces) by deleting the said 3 lines of code. In conclusion, reusable-classes are not self-contained, but can be used as parts for building SCCs. Our CBD requires making SCCs replaceable, by encapsulating all the application logic implemented for an SCC in a RCC.

Therefore, there are crystal clear differences between reusable-classes (known as reusable components) and RCCs (referred to as replaceable-components or RSCCs) and it is essential to know the clear difference. Since real-software-components are not yet known, today no other GUI-API is designed to encapsulate such large compound-SCC (that uses multiple GUI-classes and also implements necessary application logic for including multiple self-contained GUI-components) in a RCC, which is essential for achieving CBD-structure by building component hierarchies.

One important difference is: The reusable-classes must be generic and flexible (so can’t comprise application specific data/logic) to be reusable in multiple applications, where each application implements application logic to construct and configure using application data to satisfy unique needs of each of the applications. Hence large reusable-classes often can’t be self-contained and not practical to be scaled as possible for compound-RSCC. That is, it is not practical for creating reusable class for City_LandMarks, without making large number of application specific assumptions and without using any application specific data. On the other hand, the RCCs are custom designed for just one target application, hence can comprise 100% of application specific-logic/data and custom designed to not only satisfy current unique needs but also easily adaptable to often unpredictable future evolving needs of the target application.

Today neither singleton-SCCs nor compound-SCCs are designed as RCCs, which proves real-software-components are not yet known. Each reusable-GUI-class for GUI-components (e.g. Pie-chart, bar-chart or a container GUI-component containing multiple sub-GUI-components) are not self-contained, but can be used for including an singleton-SCC in the application (by implementing necessary application logic such as code for accessing and processing application data and using the application data for initializing and configuring an object instance of the reusable-GUI-class for presenting each GUI-component in each container-RSCC).

Is it possible to extract Orange juice from any other kind of fruit or vegetable (by erroneously assuming each kind of fruit or vegetable is a kind of Orange)? Likewise, it is error to assume each kind of parts (either having certain properties or conform to certain so called component models) is a kind of software-components. Using fake software-components is not CBD for software. In case of physical products, we have only few kinds of parts, such as components and ingredient-parts (e.g. steel, silicon, alloys, paint or plastic), since the physical parts are constrained by laws of nature and physical attributes (e.g. size, shape or weight).

The software-parts have no such constraints, so it is possible to invent many kinds of parts for software products, including very unique kind of parts that are logically equivalent to the physical functional-component (by having essential properties uniquely and universally shared by each and every physical functional-component) for achieving real-CBD for software.

If flapping fake wings can’t be flying, how could using fake software components be CBD for software?

Would any one accept an absurd definition that “Flying is not much more than flapping wings”? Any one who has seen birds and airplanes flying in the sky shall never accept such insane definition. Those who don’t know ‘what is flying’ could discover ‘real-flying’ by observing the aerobatic maneuvers of birds and airplanes flying in the sky. Doesn’t humankind know ‘what is CBD of the physical products’? Those who don’t know ‘what is CBD’ could discover ‘real-CBD’ by observing the design and development of a first working model of a complex one-of-a-kind product (e.g. experimental jet-fighter or spacecraft) or a unique product being invented newly (e.g. artificial kidney).

It is impossible to accept absurd definition “CBD for software is not much more than using so called software components”, if one discovers inherent nature of real-CBD (e.g. essential aspects uniquely and universally shared by design of any physical CBD-products). Our website can help researchers discover ‘what is CBD’, by briefly illustrating essential aspects uniquely and universally shared by design of any physical CBD-product (e.g. CBD-structure & CBD-process). There is no valid reason, why design of complex software must be different from design of a first working model of any complex new or one-of-a-kind physical product, once researchers discover essential characteristics uniquely and universally shared by the physical functional components for inventing real-software-components that are equivalent to the physical functional components by having the essential characteristics.

What is CBD all about and are there any essential recognizable aspects for CBD? For example, let me provide an essential recognizable aspect: Cost of any complex CBD product can be disassembled or reassembled under 3% of the total cost of designing and building all the components and the product. Any large component (even complex component having 100s of sub-components) can be located and disassembled and re-assembled as a unit, for example, to replace by a better component or to redesign and test the component individually outside (e.g. to improve the component little-by-little in step-1 or step-3 of CBD-process).

It is not necessary that even a single large component in the component hierarchy need to be reusable, standardized or have any other properties erroneously attributed to so called software components exist today. More useful CBD-facts about the design of physical CBD-products and CBD-rules for achieving real-CBD for software equivalent to the CBD of physical products is provided at as 3-CBD-rules: http://real-software-components.com/technologies/CBD-facts-rules.html.

Could any one prove there is no error in the following unsubstantiated seed postulation on which researchers of computer science and software engineering have been relying for four decades for inventing Component-Based Design for advancing software engineering: Today the term ‘software components’ is used as synonym to certain kinds of “software parts”, where each kind of so called software-components by definition (or convention) is a kind of useful parts either (1) Having certain useful properties (e.g. reusable or standardized etc.) or (2) Conforming to a so called Software Component-Model. It is impossible to find any evidence that any one else ever suspected that there could be an error or dared to question its validity.

This unsubstantiated axiomatic postulation (i.e. a mere assumption or myth) resulted in many kinds of so called software components without any consideration to facts or basis in reality. Any baseless axiomatic assumption, if it can be proved an error, is a myth. Also resulted in many kinds of CBSDs (i.e. CBD for Software), where each kind of CBSD is blindly defined as using one or more kinds of so called components (or so called component models).

When clearly informed, how could any responsible researcher or scientist ignore and do nothing, when knowing tens of thousands of researchers might be wasting their efforts for advancing the software engineering by relying on a mere myth (i.e. by erroneously believing that it is a fact). The cost of this error in past two decades must be in trillions of dollars and no meaningful progress in productivity of software engineering shall be possible until this error is exposed.

Of course, an expert doesn’t need to take our word of an unknown researcher from no where, but don’t they have intellectual curiosity and common sense. Isn’t too much to request for using simple reasoning and common sense: Isn’t it a huge error to knowingly rely on such baseless myth for scientific progress, if he can’t find evidence that it is not a myth? Furthermore our website provided ample evidence to prove possible error, which is more than enough to compel any responsible researcher to ascertain its validity (by analyzing all the irrefutable facts & valid observations).

If given opportunity, I can provide conclusive proof, where the proof is already provided openly in our website for any expert to validate. It is extremely disappointing, if no one cares about such absurd errors or it is impossible to make the responsible people aware of such absurd errors (costing hundreds of billions), for example, if they try to evade (e.g. by using silly excuses or pretend to be busy) by feeling that it is some else’s responsibility. When we successful with the help of researchers having intellectual curiosity, true love and passion for our beloved computer science, do such organizations deserve licenses to our patented Tools and inventions when, if they feel that it must be done on some else’s dime and they feel entailed to such inventions?

Many Indian software companies feel they can infringe, plagiarize, pirate or steel intellectual property, once it is proven on some else’s expense. If I have a say or able to convince other stakeholders, few companies run by such arrogant CEOs and top management would never get licenses. I feel, people who don’t feel passionately about advancing technology don’t deserve to be in technology business. What is the incentive for research for advancing the science and technology, if few people invest and take big risks and others can steel intellectual property for free?

How is it possible for any researcher to bring a disruptive discovery (which could add trillions to world economy) to notice of responsible researchers? Mankind already wasted few decades by relying on this myth. Today billions of dollars is being invested in research for advancing computer science and software engineering. Large portion of this money and effort of thousands of researchers is going to be wasted, if no one tries to validate the above myth and continue to rely on the myth (by believing that it is a fact).