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