Dear Friends,

It is possible to solve software crisis by eliminating its primary cause - spaghetti code, if I can find software researchers who knows what components and CBPs (Component-based products) are. Software crisis has been costing trillions of dollars to the global economy and killed hundreds of people during past 40 months.

I have been struggling for over a decade to find software researchers who have seen components and Component-based products, but no luck. I could not find software researchers having basic common-sense and knowledge of elementary principles or basic rules of the modern scientific method.

Today, no one in the world knows these simple verifiable facts about components, CBPs and CBE: http://real-software-components.com/raju/Info/SoftwareStuckInDarkAges.pdfconsidering objective reality http://real-software-components.com/raju/Info/HonestAnswer.pdfand simple verifiable facts http://real-software-components.com/raju/ImportantFacts2.pdf.

In light of above reality, prevailing descriptions for components make no sense and are outright crazy http://real-software-components.com/raju/ComponentDefinitions2.pdfand http://real-software-components.com/raju/WhatIsComponent2.pdf.

I am wondering, which planet are these software researchers came from? I am sure any graduate of any science or engineering on this planet must have seen and know about Components, CBPs and CBE. Today obvious verifiable facts about Components, CBPs and CBE are widely perceived to be heretical: http://real-software-components.com/raju/Info/SoftwareStuckInDarkAges.pdf

On the other hand, highly subjective terminology is used for each definition or description of software components in http://real-software-components.com/raju/WhatIsComponent2.pdf, so each definitions is being interpreted many in many different ways.

It is impossible to resolve the differences between the different interpretations, since there is no objective reference (e.g. a reference specie of physical component and CBP). For example, Botany textbooks defined or described large trees (e.g. that can be easily observed or more than 3CM in length) and wide range of subclasses of trees, we can use a concrete reference to resolve any differences in interpretation by observing the specimens of relevant class of trees.

Likewise, Zoology textbooks defined or described large animals (e.g. that can be easily observed or weighing more than 300 grams) and wide range of subclasses of the animals, we can use concrete reference specimens to resolve any differences in interpretation by observing the relevant class of animals. Based on my experience, components can be grouped into 3 to 5 trivial subclasses, while Zoology or Botany deals with 100s of times more diverse classes and subclasses of species, where each subclass is many times more complex.

To define and understand the description for animal subclass such as feline family (e.g. tigers, cheats or lions), it is possible to observe the animal species to minimize misinterpretation of terminology. Without concrete examples, it is very hard to provide and understand any description.

It is very hard to make sense of the description of Felidae in our science textbooks about Felidae for aliens, who have never seen the animal species. Existing vague or rough descriptions for so called software components are no different. There is so much subjectivity because software engineering needs to accommodate so many possible contexts, problem domains and scenarios.

Any real US lawyer must agree that it is an indisputable fact that raping minor girls is a major crime as per the US law. Likewise, any real scientist must agree that, in the context of the dominant paradigm for any major scientific or engineering discipline, it is a fatal mistake (as per the modern scientific method) to use and rely on fundamentally flawed beliefs as core first principles and would have pernicious consequences. Even basic scientific inquiry proves that the first principles about so-called software components, CBPs and CBE for software are fundamentally flawed: http://real-software-components.com/raju/CPSC/GeocentricAnalogy.pdf

Two material facts in the attached PDF conclusively proves that the software engineering is defective product that is responsible for hundreds of deaths and software education is defective service that has been causing huge harm to their careers and creativity by indoctrinating unsuspecting and impressionable students (and future software researchers) into the geocentric paradigm of software: http://real-software-components.com/raju/HugeHarmToStudents.pdf

Best Regards,

Raju