The process of scientific research is broken in the computer science and it must be fixed by following simple scientific principles of basic sciences

The real scientific process for advancing any area such as semiconductor-chips or fiber-optic networks (or real-CBD for software) requires two basic steps: (1) Basic scientific research to discover facts about innate nature and essential characteristics and aspects of the basic building blocks essential for the area, and (2) Basic engineering research that must rely on the facts discovered in the step-1 to invent useful things of the area.

The scientific and engineering progress is respective fields (e.g. semiconductor-chips or fiber-optic networks) is accomplished by iterating on two steps (e.g. by experimentation, trail-and-error): (a) discovering more facts or finer aspects of already known facts; and (b) invent more useful things or innovating to make useful things better by relying on facts.

The researchers of computer science made a huge error by skipping the step-1 by defining many kinds of software-components without any basis in reality or consideration of facts, where each kind of software-components by definition (or convention) is a kind of useful software parts either (i) having certain useful properties (e.g. reusable or standardized) or (ii) conforming to a so called component model.

The above definitions (or postulations) are a huge violation of basic scientific principle/process: Could the semiconductor-chip industry exist, if scientists define characteristics of electrons and nature of how electrons behave in semiconductor materials, without any consideration to reality or facts? Could the fiber-optic networks exist, if scientists define characteristics of light and nature of how light behave in fiber-optics, without any consideration to reality or facts?

Likewise, real-software-components for real-CBSD cannot be invented by software researchers, without discovering the facts about innate nature of real-functional-components such as unique characteristics universally shared by all the physical functional-components that are essential for enabling real-CBD (e.g. must have one or more hierarchies of replaceable components) for the physical products.

Therefore any progress made based on these baseless definitions (i.e. postulation) for so called software components would have near zero value in the context of real-CBSD. Please don't miss-interpret my statement. Of course, they have value in the context of software-parts, because it is certainly possible to invent and improve many kinds of useful software parts. These other kinds of software-parts and improvements are giving the researchers a false sense confidence that research is in the right path. But reality is other kinds of software-parts are not only irrelevant in the context of real-CBSD but also successfully preventing the discovery of real-software-component for real-CBSD (i.e. CBD for software products) by burring the error deeply under ever growing many layers upon layers of interdependent web of concepts of so called component/CBSE evolved for decades by relying on the error.

The existing software engineering paradigm (built by relying on the above huge error) has been spread very widely (even though software is widely acknowledged to be in crisis/complex, computing is far more useful to endure the complexity) and the large ecosystem of concepts evolved by relying on the error is deeply entrenched into conventional wisdom. Today most experts even arrogantly or foolishly refuse to accept the basic scientific principles and processes.

Often the experts defend the error by relying on the concepts of top-layers of the paradigm, without even realizing that they have been using invalid circular logic. It is no different that the astronomers defending the Geocentric-model by using the epicycles and retrograde-motion of planets, where the epicycles and retrograde-motion were well documented for centuries (e.g. can re-confirm at any time by observing the planets) and deeply entrenched in to collective wisdom. This resulted in a stalemate and the most famous intellectual scientific confrontation in history:

In his letter to Kepler in year 1610, Galileo complained that the philosophers (i.e. Scientists were referred to as philosophers) who opposed his discoveries had refused even to look through a telescope: "My dear Kepler, I wish that we might laugh at the remarkable stupidity of the common herd. What do you have to say about the principal philosophers of this academy who are filled with the stubbornness of an asp and do not want to look at either the planets, the moon or the telescope, even though I have freely and deliberately offered them the opportunity a thousand times? Truly, just as the asp stops its ears, so do these philosophers shut their eyes to the light of truth."

This kind of stalemate can never occur, if no basic scientific principle is violated and no scientific process is broken. Therefore this kind of stalemate can be overcome by finding any violations of basic scientific principles or broken scientific process. Those philosophers had million references to discredit the Truth (i.e. Heliocentric-model) in then deeply entrenched paradigm, which had been evolving for centuries by relying on a huge error. The philosophers had no problem showing the retrograde motion of planets to any one who wants proof (by standing on the Earth). The existing software paradigm that has been evolving since 1970 has literally has thousands of references either to defend the huge error or to discredit the facts and reality (each and every one know about the CBD of physical products and the physical functional components).

I am respectfully challenging any software expert to find a flaw in this simple two-part proof: Part-1: No real scientist can discredit the fact that, it is a huge error to skip the step-1 for technological progress. Part-2: It is impossible to find any evidence that any researcher ever tried to discover the nature of real-components essential for achieving real-CBD, which further requires discovering accurate description for real-CBD by relying on facts (e.g. CBD-structure) and valid observations (e.g. CBD-process).

It is impossible to find any evidence that inventing or defining (instead of discovering) the nature of any physical being (e.g. electrons, light or components) or phenomenon (e.g. behavior in IC-chips, fiber-optic equipment or for achieving real-CBD respectively) ever resulted in any tangible benefits, except in science fiction books and movies, or inspiring mankind’s creative imagination that might result in real discoveries. Of course, some discoveries are made either by accident or a lucky guess.

I freely and deliberately offered to demonstrate dozens of hierarchies of replaceable components to many researchers. Sadly respected researchers even in the 21st century behaved not much differently than the philosophers in the dark ages. For example, after few failed attempts I wrote this open letter to researchers of highly respected research organizations.

How could any one believe he is real researchers or scientists without even knowing the basic scientific principles and basic scientific process? If software scientists refuse to accept basic scientific principles that are applicable to the software engineering, which is amount to murdering the real-CBSD and death of real-scientific progress (since no real scientific progress is possible not only without exposing the huge error but also not following basic scientific principles and processes).

Any scientist must agree that even 5 times the collective might and wealth of mankind can’t change the laws of nature, so it is foolish to define or try to invent the nature of any kind of physical-beings or physical-phenomenon. The computer science veered off course into the realm of pseudo-science (or science fiction) when software researchers collectively accepted or agreed to define or try to invent nature of physical-beings (e.g. physical functional-components) or phenomenon (CBD for physical products).

The computer science can be and must be a real science, because it can be and must be progressed on real facts (not myths or baseless postulations). Unfortunately today the computer science is not real science because it comprises many concepts relying on myths or baseless postulations. It is impossible to transform this pseudo-science into real science without exposing the errors and myths; without fixing the broken scientific process by following basic scientific principles.

If one searchers using Google for phrases such as “Is software engineering a real engineering” or “Is computer science a real science”, one can find many articles persuasively arguing that software engineering or computer science are flawed discipline. The basic science was flawed discipline 500 years ago, because it evolved for 1000 years based on unsubstantiated erroneous axiomatic assumption “The Earth is static at center”. Likewise, computer science and software engineering are flawed disciplines, because each has been evolving since 1960s based on the unsubstantiated erroneous axiomatic assumptions (no one ever try to validate or even aware of its very existence).

The CBD is a physical phenomenon like phenomenon of flying that must obey laws of nature, and flopping fake wings (i.e. using fake components) can never achieve flight (i.e. real CBD). Our beloved computer science can never come out of realm of science fiction until the nature of beings and phenomenon is discovered (instead of relying on baseless definitions that clearly contradict reality and facts). For example, the phenomenon of controlled powered flight can’t be achieved without relying on scientific discoveries and technological facts. Likewise, it is impossible to achieve real-CBD without discovering the essential scientific and technological facts. The technological progress since early flight of Wright Brothers to acrobatic twists and turns of modern jet-fighters is possible only by relying on scientific discoveries and technological facts. By observing the progress of aviation or any modern technology one can understand that defining nature instead of discovering nature resulted in our beloved computer science ending up as a science fiction.

Humbly requesting software researchers to not forget sacred duty to pursue Truth by relying only on substantiated concepts and facts

Any real scientist must agree: the scientific progress is discovering new facts for expanding the boundaries of human knowledge. Pursuit of the absolute truths (or facts) is the basic responsibility and sacred duty of each and every real scientist or researcher. Unfortunately, many software researchers ignored or forgot this basic sacred responsibility.

Please kindly don’t forget basic scientific principles: Any real science ends up in a contradiction or paradox if and only if there is an error in the basic facts, concepts and reasoning. It is an error to rely on any subjective concept or axiom without sound basis in reality and fact, since any error certainly leads to a paradox. It is a huge error.

"By denying scientific principles, one may maintain any paradox" ---Galileo Galilee

The real scientific progress depends on researchers pursuing Truth (objective facts) with passion, since no real scientific progress is possible by relying flawed subjective concepts or erroneous postulations. Any scientific field sooner or later ends in a crisis, if scientists abdicate this sacred duty (e.g. not validating baseless axiomatic assumptions or unsubstantiated postulations).

Unfortunately, software researchers have been trying to advance software engineering by relying on a flawed root postulation since 1970. This error must have a cost of a trillion dollars to the world economy (so far). Each and every concept in computer science can be and must be objective facts, but today computer science ended up with many subjective concepts (many of them contradict reality) due to this erroneous root postulation: http://www.real-software-components.com/more_docs/SummaryAs3facts.html

Stating the fact that “the Sun is at the center” offended common sense or insulted deeply entrenched collective conventional wisdom of respected scientists 500 years ago. Likewise, unfortunately few software researchers might feel offended, when I try to point out certain errors. At any time since 1970s tens of thousands of researchers have been working very hard (e.g. applying brute force) with passion for advancing the software engineering by relying on this unsubstantiated flawed root postulation (without ever validating or even aware of the huge error). This brute force resulted in evolution of complex paradoxical paradigm with ecosystem comprising 3-dimensional web of interdependent concepts (many of them are no different from epicycles& retrograde motions resulted form the error in the root postulation).

Please kindly remember, the software engineering paradigm has been evolving since 1968 (resulting in deeply entrenched conventional wisdom and a huge ecosystem of interdependent concepts), by relying on this huge undetected error. Mankind not made this kind of error in basic seed axiomatic premises, since exposing the error of then deeply entrenched Geocentric-paradigm 400 years ago. Please kindly remember, it is invalid circular logic to use any concept (e.g. epicycles and retrograde motion) derived from geocentric-paradigm to discredit heliocentric-paradigm.

Can we even imagine designing and building complex one-of-a-kind products such as Jet-fighters or spacecrafts without componentization (i.e. partitioning into a CBD-structure or component-hierarchy)? No component in the hierarchy magically works perfectly at first attempt. Each component is refined or redesigned little-by-little to make it as best as it can be (in CBD-process step-1). This process of refining and redesigning each component would continue throughout the evolutionary life of the product-family, for example, as summarized in step-3. For example, consider design and development of a new innovative product at:

          It is impossible to find a valid reason why each of the complex software products can’t be design as component-hierarchy (i.e. as a CBD-structure), where each component can be evolved individually outside of the product, especially in light of the following two important irrefutable facts about CBD of the complex physical-products (henceforth referred to as 2-CBD-facts):

1.    It is an obvious fact that, it is not necessary that even a single component in the component-hierarchy of a product (e.g. a spacecraft or experimental Jet-fighter) conform to so called component models or have any property (e.g. reuse or standardized) erroneously attributed to the any kind of software components known today.

2.    We also know that either uniqueness or complexity of one-of-a-kind products (e.g. a spacecraft or experimental Jet-fighter) can’t prevent designers from achieving component-hierarchy (or CBD-structure).

It is an irrefutable fact that: the cost of disassembling or reassembling any complex CBD-product is under 5% of the cost of designing and building all the components of the complex CBD-product (in step-1 or step-3 of CBD-process). In light of this fact, why isn’t it possible to design each of the complex software products, so that the product try to satisfy the following three rules (hence forth referred to as 3-CBD-rules) by inventing real-software-components that are logically equivalent to large physical functional-components:

1.    The application must be built by taking a bare application template and assembling all the components, where no component need more than 2 to 5 lines of code to assemble.

2.    Removing the 2 to 5 lines must effectively remove the component and removing all the components (one component at a time) result in the original bare application template.

3.    Once all the components are ready, the product can be disassembled or reassembled for about 5% of the cost of designing and building all the components in the component- hierarchy.

After building hundreds of software GUI-applications each GUI-application (e.g. City_GIS) as a CBD-structure, I can’t find a valid reason why software applications can’t be built to satisfy the 3-CBD-rules. Let me confess that I implemented some custom code in each application template, but the custom code is about 10% of the total application code implemented for all the real-software-components. Hence, this custom code would be left in the template in case of rule-2 and costs up to 15% in case of rule-3. Of course, most of the custom code is implemented to fill gaps for doing certain routine house keeping work and communication code. Based on the earlier experience I learned that most of the custom code can be eliminated by creating and using certain generic reusable components and intelligent CASE-tools targeted at achieving real-CBD for software.

My humble request is to discover innate nature and essential properties uniquely and universally shared by each and every physical functional components, since the essential properties are useful for positively identifying equivalent software components in complex software applications. Although goal must be and can be 100% componentization of each complex application, please keep in mind that, even if 50% of the application code is created as component-hierarchies, each component can be redesigned and tested outside of the application individually at a fraction of the cost and time.