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). 

What are the right processes for scientific research for acquiring knowledge and engineering research for inventing useful things?

When did the basic processes for scientific research of our software scientific field changed to this new scientific process of defining or dictating nature and characteristics (without any consideration of reality and no basis in scientific facts), from the old fashioned scientific process of discovering innate nature and essential characteristics or aspects of physical beings or phenomena respectively.

I am stuck in the belief that, places where one can get to do cool stuff like defining laws of nature is only in certain kind of books or movies, which are popularly known as science fiction. The writers of fiction get to define laws of nature to accomplish cool stuff like time-travel, cold-fusion or star-wars (without any basis or consideration of reality or scientific facts). It is cool if scientists could define or dictate nature, but I found no evidence that such baseless definitions ever resulted in tangible benefits or useful inventions.

I am stuck with old fashioned scientific process, and belief in the process of struggling to discover innate nature and essential aspects or characteristics of physical beings such as physical-components and physical phenomena such as CBD for physical products. If this were wrong, I wasted more than a decade of my life in this foolish pursuit of scientific research for discovering facts and engineering research for using the facts to invent real-software-components for real-CBSD.

I am still stuck in old fashioned belief: (1) The purpose of scientific research is to discover facts for expanding the boundaries of human knowledge, and (2) the purpose of engineering research is to invent and build useful things by relying on the facts. The software researchers skipped the step-1 by defining the laws of nature (e.g. essential characteristics of components and essential aspects of CBD) and trying to invent useful things by relying on the definitions (having no basis in fact or reality).

If I am wrong, I wasted only my time of over 10 years and money from my family savings so far. If the researchers were wrong, mankind already lost many decades of scientific progress (at a cost of trillions in lost opportunities). For example, tax-payer funded research institutions such as SEI at CMU and SDP at NITRD has been wasting billions and sadly defending status-quo (which would cost hundreds of billions each year in lost opportunity costs) at the expense of tax-payers.

I have tried my best to inform the accomplished researchers at those respected organizations about my research results, but I was unable to get their attention. I tried to openly post in the blogs of SEI researchers, but moderators refuse to accept inconvenient facts. For example, I humbly requested the researchers to explain the baseless definitions and resulting contradictions (by relying on facts). I telephoned, but unable to get even an opportunity to explain my side.

If any one thinks I am foolish or crazy, of course feeling is mutual because: I openly provided all the evidence and willing defend only by relying on facts, while many experts refused to explain and ignoring obvious contradictions and errors (e.g. by using silly excuses such as software is different without explain why and in what manner software is different).

After exhausting all reasonable ways, I decided to write an open letter and inform the respected researchers by email and phone about the open letter hosted in our website at: http://real-software-components.com/forum_blogs/Open-letter.html  

It is impossible to find a solution to any problem, if there is a mistake in the statement of the problem

Please assume a large algebraic equation is written on the black board for a take home mathematics exam. What would happen, even for the most brilliant student, if he makes a small mistake in copying the equation to his note book (e.g. in a digit or a letter)? I am sure it ruins his weekend, if he hasn't suspect possible mistake in the equation after struggling for several hours and until try to correct it, for example, by calling his classmates for checking the equation.

He can’t solve the equation (without fixing the mistake), even if he uses every method in the books and struggles for weeks. Can software researchers afford to do the similar mistake and struggle for few more decades by using every method in the books or by inventing new methods not in the books? He can’t solve the equation, because there is no solution (due to the error). Scientific problems having error are like the equation having an error. For example, mankind could not have found a solution to Geocentric-model, even mankind struggles for another 1000 years. Today software researchers have been making the same mistake by struggling to find a solution to a problem that has no solution.

For example, Dr. Brooks persuasively argued in his famous book “Mythical Man Month” and in his seminal paper "No Silver Bullet — Essence and Accidents of Software Engineering" that there is no solution. He is right, only because there is an error in the statement of the problem. When researchers discover the error in the equation, it would be apparent that 80% of the effort is not essential cost but accidental cost (so can be eliminated). There is no spaghetti code in the CBD-structure of physical products. But today even small software applications having just 3 SCCs begins its life as a spaghetti code (for example, assume City_LandMarks of City_GIS having three sub-components is a small application). And large applications comprise of hundreds of SCCs.

Unfortunately software researchers have been working vary hard for decades to advance software engineering and CBD for software by relying on axiomatic assumption that each kind of software components is a kind of useful software parts by definition or convention either (i) having given useful properties (e.g. reuse or standardized) or (ii) conform to a given so called component model.

        The above is a huge error, for example, in light of 2-CBD-facts and 3-CBD-rules. This error wasted (i.e. ruined) many decades of research effort on component based design. The software industry is wasting tens of billions of dollars each year on creating and managing spaghetti code (e.g. Big Ball of Mud).

Yet many experts refuse to even consider possibility that, there might be a small mistake in using term “software components” as synonym to “useful software parts”, by definition or consent of recognized committees either (i) having certain properties or (ii) conform to certain so called component-model. In case of physical products (see 3-CBD-facts), no other kind of physical parts can be a component except very specific kind of physical parts having very unique set of properties, where the components are essential to achieve real-CBD.

A real paradigm shift is like a complex religious conversion

A real Kuhnian paradigm shift is somewhat like a religious conversion to a new religion having radically different belief system for an orthodox follower, who never even heard of possible existence of any other religion. For example, proposal of Heliocentric-model over 600 years ago was radical new religion for astronomers believed for many generations that the Earth is static at the center. The Geocentric-paradigm had evolved for 1000 years on the conviction that the Earth is static at the center, which had deeply entrenched in to the collective wisdom. It must never had even crossed their mind that there might be an error in the root axiomatic assumption “the Earth is static at the center” (since they or many generations before them found no reason to question this assumption).

They had overwhelming empirical evidence for the epicycles and retrograde-motions of the planets. Many generations of astronomers painstakingly documented epicycles and retrograde-motions by standing on the static Earth. Hence no one dared to question the retrograde-motions of the planets. The astronomers used the epicycles and retrograde-motions to discredit Heliocentric-model, without realizing that they were using invalid circular logic. A circular-logic can comprise of a short chain of concepts or long chain of concepts. It is hard to realize a circular-logic that comprising long chain of concepts, but it is still an invalid circular-logic, if one of the concepts in the long chain is used to prove to root postulation.

Unfortunately existing software engineering paradigm has been evolving by relying on a flawed root postulation(or axiomatic assumption) for decades and resulted in a complex ecosystem having many long chains of interdependent concepts and deeply entrenched collective wisdom. Today saying software parts equivalent to ingredient parts such as cement, paint, steel, silicon or alloys are not real components for achieving the real-CBD for software, is blasphemous or offends common sense of software researchers. It feels like asking one to convert to new religion, where he doesn’t even imagine possibility of another religion (i.e. possible existence of more than one religion or even atheism).

I am humbly requesting researchers to discover innate nature and essential properties that are uniquely and universally shared by the physical functional components, where the essential properties are very useful for achieving component-hierarchies (an essential requirement for the real-CBD). This exposes error in the root postulation (or axiomatic assumption) of deeply entrenched conventional wisdom of existing paradigm and accomplishes another important task: It is not hard to invent equivalent software components (having the essential properties, once the essential properties are discovered) for achieving real-CBSD (CBD for software), which is equivalent to the CBD of physical products such as one of a kind products such as experimental Jet-fighters or spacecrafts.

These new products are designed as component-hierarchies (or CBD-structure), where each component can be designed and tested individually outside of the product. Once all the components are ready, the total cost of disassembling or reassembling could never be more that 5% of the total cost of the product throughout the life of the complex product (i.e. in step-1 or step-3 of CBD-process). Please let me summarize two essential aspects CBD-Structure and CBD-process of real-CBD of physical products in separate web pages: http://real-software-components.com/CBD/Real-CBD.html

It is extremely important to recognize two important facts about the CBD-design (i) It is not necessary that even a single large functional component in the CBD-structure (or component-hierarchy) of a complex product to conform to any known so called component models or have any useful properties (e.g. reuse or standardized) erroneously attributed to software components today. (ii) Either complexity or uniqueness of one-of-a-kind product (e.g. experimental spacecraft) can’t prevent the designers from partitioning the product as component-hierarchy.

Please kindly look at design of a sample application that is designed as hierarchy of real-software-components that are equivalent to the physical functional-components for achieving CBD-structure (or component-hierarchy): http://real-software-components.com/CBD/City_GIS.html

The componentization is the most effective and efficient method known to mankind for addressing a complex problem (i.e. by a team of experts) by partitioning the complex problem in to hierarchies of smaller (or components) and smaller (or sub-components) self-contained problems, where each smaller self-contained problem can be addressed individually (by each member of the team in manner consistent with his domain expertise, knowledge and skills): http://real-software-components.com/technologies/componentization_purpose.html

The software engineering researchers committed a huge mistake not analyzing all the facts and valid observations for discovering the innate nature and essential properties of the physical functional components. It is not a small error: http://real-software-components.com/forum_blogs/year2013/IsItSmallError.html