Dear Dr. Gruenwald,

High school science classes teach kids how to find valid descriptions for things (by observing them objectively with a scientific eye) like animals, birds, trees, fish, bacteria, viruses, orgonic, inorganic compounds, atoms, light etc. All I am requesting is for software researchers and experts to do what high school students can do and find valid scientific descriptions for components and CBPs (Component-Based Products).

Today, it is impossible to find software (or Computer Science) scientists, researchers, or experts who are willing to scientifically investigate evidence and facts to find valid scientific answers or facts for valid descriptions for physical things such as Components and CBPs.

Let me provide valid scientific answers. A product can be a CBP (Component-Based Product), if and only if the product is built by assembling multiple components. A part can be a component, if and only if the component can be assembled (e.g. in order to build CBPs). The software community today perceives these simple scientific facts and objective reality to be strange, alien, and heretical:

In all other engineering disciplines, a product can be a Component-Based Product if and only if the product is built by assembling multiple components, where each component is a very specific kind of part that can be assembled. In all other engineering disciplines, a part can be a component if and only if the part can be assembled. No other engineering discipline refers to any other kind of part (that cannot be assembled but is similar or analogous to an ingredient part) as a component.

Please see attached PDF for how it is possible to solve software crisis by addressing spaghetti code by finding valid scientific answers. – Keep in mind that, all the other engineering paradigms addressed such crisis by building large products by assembling optimal sized components.

Best Regards,

Raju Chiluvuri

Dear Friends,

Let me summarise my earlier message. Does this simple scientific fact require any reference to, in the context of all other engineering disciplines: A product can be a CBP (Component-Based Product), if and only if the product is built by assembling multiple components as illustrated in FIG-2, where the components are very specific kind of parts that can be assembled?

📷

Isn’t this presumption obviously wrong: It is not a CBE (Component-Based Engineering), if each product is built by using other kinds of parts (e.g. reusable parts that are similar or analogues to ingredient parts) as a monolith as illustrated in FIG-1? http://real-software-components.com/raju/Briefs/WhatIsStructureOfCBP.pdf

Isn’t it shocking, if researchers of software demand reference to the above obvious scientific facts about physical components and CBPs? I could not figure out how I can respond to this question.

I searcher whole web for years and not able to find any reference to this observable fact that each CBP such as cars, computers, machines or airplanes are built by assembling multiple components as illustrated in FIG-2, where the components are very specific kind of parts that can be assembled?

If the above scientific facts are understood, it is not difficult to transform software engineering to CBE paradigm: http://real-software-components.com/raju/Briefs/TransformingToCBE.pdf. I have secured 7 patents (so far) for the three essential inventions.

Best Regards,

Raju Chiluvuri

Raju,

You describe these as two simple and related questions. I’ve worked in many different areas of design and research and found the simple questions are the most complex. Usually avoided because we “simply” don’t know. I used to translate this into, “at this time we’re not able to figure out what the real the question is”.

In my experience with projects, especially ones that linked packages for computer-aided-design, predictive analysis and manufacturing it was extremely hard for the developers to track and understand the details of the code. I found during code writing if I sat along side and watched and asked questions many of the unnecessary patches to mysterious spaghetti was reduced.

Also, like you, I can’t find anything on the internet. It implies that we don’t ask about this. - I’d be somewhat OK (???) if we asked in the past and economics of code writing (delivery time et al) made it too costly to ensure better accuracy. But my search attempts today gave me results for over 20 pages related to border protection (???) and literally nothing for your question. Not even in publications.

My opinion, in 2021 this is no longer excusable. But while the seriousness spaghetti errors and entanglements increases I still don’t know how to make it better.

I’m sorry, I don't know, But- I don’t know how to even ask smaller questions to learn parts of your question. Possibly we haven't figured out how to the ask your question yet.

Dear Mr. Clawson,

There will be a revolution in Software Engineering (by subverting the existing flawed dominant paradigm that is rooted in primordial, unproven, and flawed dogma), if software community investigates facts and evidence scientifically to learn valid scientific answers and descriptions honestly, objectively and with integrity (without violating proven elementary scientific principles), for these two simple questions in the context of all other engineering disciplines such as Mechanical, Electronic, Computer, Civil, and Aerospace:

1. What is a real CBP (Component-Based Product)?

2. What are real Components (i.e. a very specific kind of parts) that are essential to building real CBPs?

I have been doing research on Components and Component-Based Products for nearly 20 years and secured 7 patents so far. Software engineering is in crisis not because it is difficult to invent components to build component-based products, but because software researchers refuse to find out valid answers scientifically.

A paradigm shift is often involving intellectual battle between “heretical scientific facts” (e.g. Sun is at the centre) and primordial “sacred lies” (e.g. Earth is at the centre”) in the pre-paradigmatic foundation: http://real-software-components.com/raju/Briefs/WhatIsStructureOfCBP.pdf

Understanding the following two simple facts scientifically subverts existing flawed dominant paradigm for Software Engineering by exposing primordial myths in the foundation of the paradigm. Do these two simple facts require any proof: (1) No product can be a CBP if the product is not built by assembling multiple components (e.g. as illustrated in FIG-2). (2) It is essential to invent new kind of components (e.g. objects instances) that can be assembled, by inventing mechanisms and tools (e.g. such as a SoA as in FIG-2) for example, to build a product by plugging in components:

Once valid answers and descriptions for CBPs and Components are found scientifically (without violating proven scientific principles), it is not difficult to make inventions that are necessary to build every large software products by plugging in multiple optimal-sized components as in FIG-2. My goal is to prove these 3 facts:

1. CBE (Component-Based Engineering) implies designing and building CBPs, where a CBP (Component-Based Products) implies a product built by assembling multiple components as illustrated in FIG-2, and where the components are a very specific kind of parts that can be assembled.

2. Today, it is impossible to find even a single software product that is designed and built by assembling real software components as illustrated in FIG-2. Therefore, Software Engineering is not employing real CBE paradigm today, since real software components (i.e. a very specific kind of parts that can be assembled) are not yet known and Software Engineering is incapable of building CBPs.

3. It requires three kinds of inventions to transform Software Engineering from the inefficient non-CBE paradigm to the ten times more efficient real CBE paradigm that can design and build every software CBP as illustrated in FIG-2 by assembling multiple optimal-sized software components: http://real-software-components.com/raju/Briefs/TransformingToCBE.pdf

Best Regards,

Raju Chiluvuri

Very interesting. Yes you are right. In order for a specific field of research and scientific knowledge to develop effectively, all paradigms, the language of the problem, key determinants of development, etc. of the specific issue should be fully explained.

Best wishes,

Dariusz Prokopowicz

Dear Dr. Prokopowicz,

Thank you. I have been struggling to expose invalid knowledge that is the root cause for software crisis. Any scientist must know these three simple common-sense facts: (i) Invalid knowledge creates problems (or crisis). (ii) Valid knowledge is essential to solve problems (or crisis). (iii) It is impossible to solve any problem that is created by invalid knowledge without acquiring valid knowledge. The history of science and engineering has many examples to prove these three simple common-sense facts.

More about Good & Bad Knowledge at: https://bit.ly/3wSJllX

I can bet my life on the following two facts, and I deserve and demand for a proper opportunity to prove these two facts beyond any doubt: (1) The root cause for infamous software crisis is the existing invalid (i.e. misleading and deceptive) knowledge about components and CBPs (Component-Based Products). (2) The software crisis can be solved by acquiring valid knowledge about components and CBPs (i.e. It is not hard to invent such real components for software to build every large software product as a CBP).

I launched a compliment against NSF.gov staff for racial discrimination for not properly validating my proposal and planning to file a court case if proper opportunity is not given to me. I offered to face criminal prosecution, if I am given an opportunity and if I fail to prove the above two facts.

Valid Knowledge: (1). https://bit.ly/2RZlS3C (2). https://bit.ly/34zYfkG

Best Regards,

Raju Chiluvuri

Pretty pictures can make things look simple, yet the complexity still resides somewhere. Using an aircraft example, Shop Replaceable Units are serialized pieces of an aircraft's avionics equipment. They are called that since you have to take the Line Replaceable Unit that includes all these smaller units to the shop to get them replaced. An aircraft can have many Line Replaceable Units that form the component structure that allows the whole aircraft to function. Many of the components also have software. Each piece of software is also identified with their serial numbers (computer product identification number or CPIN) to keep them straight. The nomenclature of each LRU, SRU, and CPIN help humans find the right ones to change. In modern software systems the microservices become a garbage heap if not named and serialized. It takes very little time for each item to retain the integrity of contribution to the whole.

Dear Mr. Casaubon,

Thank you for your comments. Kindly watch this most insightful video on current state of science. If you don’t watch this, I am sure you will regret in the future. I assure you that it is the best 1 minute 44 seconds you have ever spent. Let’s stop this stupidity of academia: https://www.youtube.com/watch?v=dGDbpg1nG8Y

Let’s observe. Let’s think. Let’s discuss: About the facts and reality of physical Components and Component-Based products. http://real-software-components.com/raju/pdfs/CBE_and_CBP.pdfand http://real-software-components.com/raju/Briefs/WhatIsCBP3pg.pdf. No one in the software world willing to accept these obvious facts, until I can find support in peer reviewed papers.

You can’t find this kind of practical real world valid knowledge in peer review publications that are reviewed by brainwashed academia who wants to be anonymous (so don’t want their invalid knowledge filled with prejudice, biases and myths to be challenged or exposed). We must change this.

Best Regards,

Raju Chiluvuri

Dear Raju,

Your first question doesn't make any sense because it embodies a logical contradiction. In order to give a definition of component-based product we have to know what a component-based product is, but we can't know what a component-based product is until we give a definition for it. To put this another way, you use the term "component-based product" to represent both an independent concept and a dependent concept in your question. A question that depends on itself does not have a logically valid answer. A question without a logically valid answer cannot have a scientifically valid answer.

Without an accepted definition for component-based product your second question doesn't have any meaning because its terms are not defined. Questions that are not meaningful don't have answers that are meaningful. A question without a meaningful answer cannot have a scientifically valid answer, either.

I don't believe that you will be able to make any progress on improving software quality (e.g., eliminating spaghetti code) unless and until you break out of the logical traps represented by these questions.

Best regards,

Stan Sutton

Dear Dr. Sutton,

I have 20 years of experience in building software CBPs (not including 70 man-years of software engineers, who are employed to build, test and experiment various patented inventions) and I can assure you that spaghetti code can be eliminated. It is possible to increase productivity by 5 folds, quality by 10 folds and agility by 10 folds by using existing patented first generation tools.

Let me summarise briefly in simple terms:

What is a CBP (Component-Based Product)? Let’s observe. Let’s think. Let’s debate: Cars are CBPs, since each car is built by assembling multiple components. Computers are CBPs, since each computer is built by plugging-in multiple components into a mechanism (e.g. equivalent to system board) as illustrated in FIG-2.

However, buildings (or houses) are not CBPs, since each building (e.g. a house) is built by using reusable parts (e.g. ingredient parts such as cement, concrete, steel, metals, wood, plastic, bricks, tiles, and paint) as illustrated in FIG-1. Likewise, executable for each software product is built as monolith as illustrated in FIG-1 by using reusable parts that are similar or analogous to ingredient parts: http://real-software-components.com/raju/TwoKindsOfParadigms.pdf

Understanding the following two simple facts scientifically subverts existing flawed dominant paradigm for Software Engineering by exposing myths in the foundation of the paradigm. Do these two simple facts require any proof: (1) No product can be a CBP if the product is not built by assembling multiple components (e.g. as illustrated in FIG-2). (2) It is essential to invent new kind of components (e.g. objects instances) that can be plugged-in, by inventing mechanisms and tools (e.g. such as a SoA as in FIG-2) for example, to build a product by plugging in components.

I have been doing research on real-CBE for over 20 years and secured multiple patents from the USPTO. I am planning to file a case against NSF.gov. These elementary common-sense scientific principles will be basis for my case: (i) Invalid knowledge creates problems (or crisis). (ii) It is essential to gain valid knowledge to solve problems (or crisis). (iii) It is impossible to solve any problem (or crisis) that is created by invalid knowledge without acquiring valid knowledge.

Evidence-1: I will tender an unconditional apology and I am willing to face prosecution if anyone can show me even a single large software CBP (Component-Based Product) or Components that can be assembled to build CBPs as illustrated in FIG-2): http://real-software-components.com/raju/pdfs/CBE_and_CBP.pdf.

Evidence-2: There are three kinds of inventions that are essential to building any large software product as a CBP (i.e. by assembling multiple components as illustrated in FIG-2). I have secured patents for each of these three kinds of inventions. USPTO does not grant patents for inventions that already exist. Each kind of invention plays an essential role in building CBPs. I will tender an unconditional public apology and face prosecution if anyone can present prior art for any of these three kinds of inventions: http://real-software-components.com/raju/Briefs/TransformingToCBE.pdf

Even tenth grade students can understand that FIG-2 represents a CBP (Component-Based Product) that is built by using parts that can be plugged into a mechanism shown as SoA. Also they can understand that FIG-1 do not represent a CBP, which is built by using other kinds of parts that are reusable or standardised.

Isn’t it invalid knowledge, if software community teaches knowledge that leads to the conclusion that FIG-1 represents CBE (Component-Based Engineering)? Isn’t it absurd: In the context of software, the FIG-2 is not a CBE, since code base for almost every component in FIG-2 is custom designed (by using reusable parts) to fit perfectly and perform optimally for the target product?

P.S: What is the function of knowledge: http://real-software-components.com/raju/pdfs/FunctionOfKnowledge.pdf

Presentation What is the objective reality and structure of Component-Bas...

Best Regards,

Raju Chiluvuri

Dear Dr. Sutton,

I am asking you to find valid descriptions scientifically for CBP (Component-Based Products) in the context of other engineering disciplines (i.e. Mechanical, Electronics, Computer or Aerospace) that design and build CBPs. Also, find valid descriptions scientifically for components that are essential for building each of the CBPs.

What is a CBP (Component-Based Product)? Let’s observe: Cars are CBPs, since each car is built by assembling multiple components. Computers are CBPs, since each computer is built by plugging-in multiple components into a mechanism (e.g. equivalent to system board) as illustrated in FIG-2.

Both CBPs and Components are physical things, so it is impossible to gain valid knowledge by blatantly violating scientific principles. But existing definitions for so called components has no basis in reality of fact – This is the invalid knowledge that created the problem or crisis.

Valid knowledge can solve the crisis. Please gain valid new knowledge and scientific insights to invent software components that can be plugged-in to build CBPs for software.

Such new knowledge and new scientific insights never be accepted, unless you file a court case. Please see the video again at 1 minute: https://www.youtube.com/watch?v=rt0m4PltGHA.

"The great enemy of the truth is very often not the lie — deliberate, contrived and dishonest — but the myth — persistent, persuasive, and unrealistic. Too often we hold fast to the cliches of our forebears. We subject all facts to a prefabricated set of interpretations. We enjoy the comfort of opinion without the discomfort of thought." ... John F. Kennedy

If we want to know or understand about any physical thing (e.g. animals, trees, bacteria, viruses, light or chemical compounds), we don’t define them but observe them with a scientific eye. The purpose of each scientific discipline is gaining such valid knowledge.

I am asking software researchers to do the same and gain valid knowledge scientifically about CBPs and Components that are essential for building the CBPs. I solved software crisis by using this valid knowledge about CBPs and Components.

After working in Silicon Valley between 1988 and 2002 as software engineer, I don’t read any software engineering books any more. It is nothing but garbage – Filled with invalid misleading or deceptive knowledge.

Best Regards,

Raju Chiluvuri

Dear Dr. Sutton,

Other scientific disciplines such as Botany, Zoology, Chemistry, Physics, Virology or Bacteriology do not define various physical things such as trees, animals, chemicals, light, atoms, viruses or bacteria. Each of them provides valid description scientifically various physical things.

Likewise, I am asking to find valid description scientifically for CBP (Component-Based Products) and Components we know and use in other engineering disciplines that are certainly CBE (Component-Based Engineering) Disciplines such as Mechanical, Electronics, Computer or Aerospace.

Even the greatest of painters cannot draw the picture of an elephant if they do not know what an elephant is (i.e. whether it is a kind of tree, fruit, building, landmark, flower, animal, fish, or bird)? I have seen even elementary school kids learned to draw decent pictures of elephants by undergoing a just few hours of training. It is not difficult to draw the picture of an elephant if one knows what an elephant is.

Likewise, it is not hard to invent real software components that can achieve real CBE for software (to build every software product as a CBP) if valid scientific knowledge is gained about (i) nature and essential properties of physical components and (ii) structure and anatomy of CBPs. Few facts: http://real-software-components.com/raju/ImportantFacts.pdf

Discovering and proving right answer to this core question (i.e. which planet is at the center) changed the course human history. Likewise, finding the right scientific answers or descriptions scientifically about physical things (i) “what is a CBP, and (ii) what are the right kind of components that are essential for the CBP” can change the course of Software Engineering and Computer Science.

There is no scientific work that is more demeaning and humiliating than struggling hard to subvert a dominant paradigm. Most of the experts loathe me for steadfastly defending heretical scientific facts and trying to expose sacred lies (i.e. flawed myths having no scientific basis). I hope you are not one of them, who loathe me.

If you ask a painter to draw picture of an elephant (who doesn’t know what an elephant is), he is supposed to observe elephants to describe the elephants. He cannot define elephants blindly without any basis in reality.

All these existing definitions for components have no basic in reality: http://real-software-components.com/raju/ComponentDefinitions.pdfand http://real-software-components.com/raju/WhatIsComponent2.pdf.

Only the God has more mysterious descriptions than components, as if no one alive has ever seen physical components (such as CPU, Memory-card, Hard-drive, Car battery, engine or gear-box) and CBPs (such as Cars or Computers). Software research community ostracized me for challenging such baseless myths. Isn’t it shameful?

Kindly keep in mind that I am not speculating the results. I have been working for past 20 years on these inventions. In addition to my 20 years research, my team of junior software engineers invested over 70 man-years on experimentation, testing and validation of the inventions by creating several hundreds of CBP (Component-Based Products) by plugging in real software components. I already secured all the necessary patents: http://real-software-components.com/raju/pdfs/PatentedInventions.pdf

Best Regards,

Raju Chiluvuri

Dear Ragu,

I don't see that the elaboration of your argument does anything to help resolve the circularity of your questions.

It seems to me that you are asking children not to draw elephants but to draw dragons.

Best regards,

Stan Sutton

Dear Dr. Sutton,

I am sure you are joking. I am sure, biologists don’t define what a tree is. High school science classes teach kids how to find valid descriptions for things (by observing them objectively with a scientific eye) like animals, birds, trees, fish, bacteria, viruses, organic, inorganic compounds, atoms, light etc.

All I am requesting is for software researchers and experts to do what high school students can do and find valid scientific descriptions for physical components (e.g. CPU, DRAM, network-card, Hard-drive, Car-battery, Engine, Gear-box or CD-player) and CBPs (Component-Based Products) such as cars, computers, airplanes and other machinery.

Today, it is impossible to find software (or Computer Science) scientists, researchers, or experts who are willing to scientifically investigate evidence and facts to find valid scientific answers or facts for valid descriptions for physical things such as (e.g. CPU, DRAM, network-card, Hard-drive, Car-battery, Engine, Gear-box or CD-player) and CBPs (Component-Based Products) such as cars, computers, airplanes and other machinery.

No scientific discipline blindly defines nature and properties without any basis in reality or facts. Can I define elephants are one-feet tall animals that live in deep sea? Can I define dogs lay eggs, and chicken give birth to baby birds?

If you want to know, weather dolphins lay eggs or give birth to baby dolphins, no real scientist is going to define blindly without observing them (and expect the nature to change the course to satisfy the definition). Dogs don’t start laying eggs from tomorrow, if you define that dog lay eggs. This is the nature of components: http://real-software-components.com/raju/ImportantFacts.pdf

Only the researchers of Computer Science made such foolish mistakes not only about components but also about neurons. Can you give a valid reason, why we cannot invent software neurons to emulate biological neural networks to invent human like computer intelligence? We are not breaking any laws of nature, since nature already find the solution.

I hope you can understand these elementary common-sense scientific principles: (i) Invalid knowledge creates problems (or a crisis) (ii) It is essential to gain valid knowledge to solve problems (or a crisis) (iii) It is impossible to solve any problem (or a crisis) that is created by invalid knowledge without acquiring valid knowledge.

Best Regards,

Raju

Dear Friends,

The Root cause for software crisis is that software researchers blindly defined nature and properties of components for software without any basis in reality, where the nature and properties are in clear contradiction to the objective reality and obvious facts, we know about physical components that are essential to build CBPs (Component-Based Products) such as Cars, Computers, Airplanes, or machines..

High school science classes teach kids how to find valid descriptions for things (by observing them objectively with a scientific eye) like animals, birds, trees, fish, bacteria, viruses, organic, inorganic compounds, atoms, light etc.

All I am requesting software researchers and experts is to do what high school students can do and find valid scientific descriptions for physical components (e.g. CPU, DRAM, network-card, Hard-drive, Car-battery, Engine, Gearbox or CD-player) and CBPs (Component-Based Products) such as cars, computers, airplanes and other machinery.

No other scientific discipline blindly defines nature and properties without any basis in reality or facts. Can I define dogs lay eggs, and chicken give birth to baby birds and feed them milk?

If anyone wants to know, weather dolphins lay eggs or give birth to baby dolphins, no real scientist is going to define blindly without observing them (and expect the nature to change the course to satisfy the definition). Dogs don’t start laying eggs from tomorrow, if scientific community unanimously defines that the dogs lay eggs.

In the world we all grew up, any product can be a CBP (Component-Based Product), if and only if the product is built by assembling multiple components, where components are very specific kind of parts that can be assembled. In other words, any part can be a component for a CBP, if and only if the part can be assembled (or plugged-in).

What is a CBP (Component-Based Product)? Cars are CBPs, since each car is built by assembling multiple components. Computers are CBPs, since each computer is built by plugging-in multiple components into a mechanism (e.g. equivalent to system board) as illustrated in FIG-2.

However, buildings (or houses) are not CBPs, since each building (e.g. a house) is built by using reusable parts (e.g. ingredient parts such as cement, concrete, steel, metals, wood, plastic, bricks, tiles, and paint) as illustrated in FIG-1. Likewise, executable for each software product is built as monolith as illustrated in FIG-1 by using reusable parts that are similar or analogous to ingredient parts: http://real-software-components.com/raju/TwoKindsOfParadigms.pdf

There are certain differences between software engineering and other engineering disciplines: http://real-software-components.com/CBD/main-differences.html, which are not difficult to understand and address, when making necessary inventions to design and build each large software product as a CBP.

Thoughts or opinions expressed by Dr. Sutton above represent current state of thinking of software research community. What he said has unanimous acceptance in software research community today. I have been struggling to overcome such misconceptions for 12 years.

It is impossible for any evidence and facts to be peer-reviewed, if the evidence and facts challenge the misconception. Hence, it is a live example for this: https://www.youtube.com/watch?v=rt0m4PltGHA

If all the peer-review journals say that Dolphins lay eggs, it is impossible to prove that they give birth to babies. No one wants to see the proof. Likewise, no one wants to see the proof that a part can be a component (e.g. to a build CBP), if and only if the part can be assembled. In general components for software are custom designed to fit perfectly and perform optimally in just one product, so not reusable.

Best Regards,

Raju Chiluvuri

Dear Friends,

If you ask any software expert or researcher two simple questions, (i) what a component is, and (ii) what a CBP (Component-Based Product) is, he will give you answers with 120% confidence that his answers are right answers, but reality is that the answers are not only wrong but also misleading and deceptive, in the context of any engineering discipline such as Mechanical, Electronic, Computer or aerospace.

Components and Component-Based Products are more mysterious and enigmatic than anything else including Quantum entanglement or structure of elementary particles. Please see related question: https://www.researchgate.net/post/Can_anyone_in_the_world_knows_or_wants_to_know_valid_scientific_answer_to_two_simple_questions#view=60ba2d8c1cb86874d767574c

I agree that we know very little about Quantum entanglement or structure of elementary particles (e.g. String Theory), but we don’t have huge invalid BoK (Body of Knowledge) and us the BoK to invent technological solutions.

In case of Components and CBP, almost all the BoK we have in textbooks is invalid and software engineering researchers blindly rely on the BoK to invent technological solutions: http://real-software-components.com/raju/Briefs/SacredLiesVsHereticalTruths.pdf

P.S: My intention is to expose the stupidest mistake in the history of science. Attached PDF contains draft question I am planning to ask next week.

Best Regards,

Raju

Raju Chiluvuri,

For 2 weeks I’ve followed the posted comments and read your responses. I regret to say I no longer agree with the sensibilities of your question.

I suggest it’s not us who can or should provide an answer. You need to demonstrate to us these ideas can work in the current (2021) world of software and hardware development. An environment that interacts with mobile devices and the internet and the security threats of today***.

Any idea, no matter how promising, needs to live in, be exposed to and interact with the environment it will be part of. And it’s your responsibility, not ours, to expose your idea to the environment of 2021. It’s your responsibility to engage the software and hardware community (publishing your research and discussing it at conferences) and find the “simple” answer (personally I believe its far from simple).

In the US, due to their devotion to common sense the state of Missouri is called the "Show-Me" State”. I’m asking the same from you, “show me” examples of results of the application your concepts.

In my experience in design and research I don’t work to find answers. Instead I work on and explore concepts over time by testing my solutions in a real world environment. That means I consider (as best as I can understand them) the needs of my culture, its people and communities, our finances and resources - and expect my ideas to develop and change.

You claim that software engineering is in a crisis but I don’t see support for this claim. I read your web site but don’t see it there either. Instead it contains claims that pull on my fears of a failures. I looked for the science and don’t see the actual work. I looked for signs of your activity with the scientific and software engineering community and don’t see attempts to experiment and test how your ideas would interact with others.

From Your web site…

“The scientists and researchers of computer science have been working very hard to advance our beloved field of software engineering since late 1960s, by relying on a huge erroneous axiomatic assumption that, software-components are nothing but certain ‘kinds of software parts', where the software parts belong to each kind are defined by either having given useful properties (e.g. reusable, standardized) or conforming to a given so called component model.”

I couldn’t find anything that supported and/or explained what the “huge erroneous axiomatic assumption” is or who exactly continues to make them.

As far as I know we’ve (in the US) made/make extensive use of component models to save development costs and bring software to market faster. We also try and re-use and repurpose components. The failures I experience are how these components interact with other components, the OS, the hardware and the internet in a compiled environment. It’s not “spaghetti code” as much as failings in our ability to foresee and plan the relationships of the components coming from multiple sources.

With regard to “Respectful requesting help of experts in this noble effort for discovering fundamental Truths for exposing the Errors in First Principles for software components & CBSD”

This too is your responsibility. Test your assumptions of the fundamental truths. Re-examine your first principles and how they work in today’s environments. Then publish the and speak about them in conferences. Put aside all the “hype” about fundamental truth and do the work need to bring your ideas into the community.

*** My concern for software is different. We’re being exposed to software –also- being used for geo-political purposes. Today I’m asking if component software parts made by and delivered from foreign countries have hidden features make us more or less secure ??? This week TikTok announced it collect extensive biometric data (phone login fingerprints, voice and faces) - My current software need is secure data in an increasingly risky world.

Dear Mr. Clawson,

Kindly refer to the attached PDFs. One PDF summarises my patented inventions that solves software crisis: SummaryOfInventions.pdf

Another PDF provides conclusive evidence from the horse’s mouth: ProofFromHorsesMouth.pdf

P.S: I stated that I am willing to face criminal prosecution, if I am wrong. These files are prepared for NSF.gov and I sent them legal notice for discrimination. I agreed to face criminal charges, if my allegation of their misconduct or negligence are unfounded. I am a naturalized US citizen, did MS in Ohio University had 4.0/4.0 GPA and worked in Silicon Valley

Kindly keep in mind that I am not speculating the results. I have been working for past 20 years on these inventions. In addition to my 20 years research, my team of junior software engineers invested over 70 man-years on experimentation, testing and validation of the inventions by creating several hundreds of CBP (Component-Based Products) by plugging in real software components.

Our patented inventions are merely tools to create pluggable components and assemble components, and not components. Please see this PDF: ReuseModularization.pdf (you need to implement your own components).

Best Regards,

Raju Chiluvuri

Dear Mr. Clason, Forget about a minute that you are a software engineer. Assume that you are a scientist exploring in the forest for new species, and document their properties, when you find new kind of species (by observing them with a scientific eye).

Likewise, you need to observe physical Components that are assembled to build CBP (Component-Based Products) such as cars, computers, machines or cell-phones, in the context of all the other engineering disciplines such as Mechanical, Electronic, Computer or Aerospace engineering.

For example, one such document I created more than 12 years ago at: http://real-software-components.com/CBD/main-differences.html

Kindly watch this interesting video that summaries pathetic state of science: https://www.youtube.com/watch?v=dGDbpg1nG8Y. Just observe and think.

Software researchers demand references in peer-reviewed journals for obvious facts such as (1) a product can be a CBP (Component-Based Product), if and only if the product is built by assembling multiple components, and (2) any part can be a component to build CBPs, if and only if the part can be assembled.

No software researcher or scientist in the world knows or aware of these two obvious facts, and none of them accept these facts, since it is impossible to find references to these facts in any textbook or peer-reviewed journal.

Best Regards, Raju

This discussion is a typical example of a dog chasing its own tail. It's usually causd by conditioning of the human brain-mind complex by "time", "money" and "mathematics".