Dear Friends,
I have been struggling for many years to educate software researchers about two simple facts (i) there are two kinds of engineering paradigms, which are Component-based and non-Component-based as illustrated at: http://real-software-components.com/raju/TwoKindsOfParadigms.pdfand (ii) today engineering discipline for Civil, Chemical or Software not employing Component-based paradigm. I shall not relent until the unknown fact (i.e. today software engineering is not employing Component-based paradigm) is understood and accepted.
Until the above unknown fact is known, no one in software industry will try to invent tools, methods and technologies essential for transforming software engineering paradigm from (a) complex, inefficient, and error-prone non-Component-based paradigm (that is infested by notorious spaghetti code) to (b) Component-based paradigm that is ten-times more efficient (e.g. by eliminating the notorious spaghetti code from design and development of each large or complex software product).
History of industrial engineering proves that Component-based paradigm can increase manual productivity, quality and agility (where the agility can reduce total cost of ownership such as maintenance and redesign) by ten times: http://real-software-components.com/raju/Briefs/BenifitsOfRealCBE.pdf.
Today each large software product (i.e. an excitable code) is built as a big monolith as illustrated by FIG-1, which is certainly not a Component-based-paradigm. Today software experts insist that FIG-1 represents Component-based paradigm, since it uses reusable parts or modules that are composed but are not assembled. Please refer to figures in the attached PDF.
Essential condition for Component-based paradigm is building each product by assembling multiple modules or components as illustrated in FIG-2, which requires invention of real software components that can be assembled, and essential tools and mechanisms for plugging-in all the components to build the software product.
For example, even in case of Civil engineering, it is possible to increase manual productivity by ten times (by employing even a rudimental and primitive Component-Based paradigm) such as: https://www.youtube.com/watch?v=AhLk7L1B_fE. But such component-based paradigm requires very expensive material or components.
That is, Civil engineering has a huge drawback – Cost or material for building all the components is 5 to 7 times more, which increases the total cost of each building 3 to 4 times (compared to existing method that uses cheaper material cement, bricks, concrete, sand and steel). The cost of material is about 80% of the cost of the building.
In case of software, over 90% of the cost is spent on manual effort for designing and building large code base of each software product, which includes design and development of code for each of the modules/parts used in the software product and more code for integrating the modules/parts to build the product. In fact, cost of material (i.e. code) to build each module is much cheaper in case of software products that are designed and built by employing real-Component-based paradigm.
The following three inventions are essential for achieving effective CBE-paradigm for software and we already secured patents for the 3 inventions: http://real-software-components.com/raju/pdfs/PatentedInventions.pdf
1. Simple and effective methodologies for partitioning each large software product in FIG-1 into multiple self-contained modules or components in FIG-2,
2. Inventions of missing technologies or tools necessary for creating and using self-contained modules or components in FIG-2 for building the product, and
3. Inventions of tools and mechanisms that can automate various tasks and activities to create, redesign, and manage communication code that is essential for allowing communication between the modules and components.
In summary, it is not hard to prove this simple rule: If an engineering paradigm that designs and builds large or complex products (without using Component-based paradigm), it is not hard to increase manual productivity by ten-fold for designing and building each large or complex product, by transforming the engineering paradigm to Component-based paradigm: http://real-software-components.com/raju/Briefs/BenifitsOfRealCBE.pdf.
Software engineering is most certainly not an exception to above rule. But no one in the software community is willing to explore the possibility of transforming software engineering to Component-based paradigm (as illustrated in FIG-2), since everyone falsely concluded that software engineering already employing components and Component-based paradigm.
Therefore, I am forced to expose this unknown heretical fact that, software engineering is not employing Component-based paradigm: http://real-software-components.com/raju/Briefs/InventionBriefly.pdf
Best Regards,
Raju Chiluvuri
Dear Raju Chiluvuri,
Very interesting. Software engineering is a highly developmental field, so what you highlighted should be fully explained.
Regards,
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: Presentation What is the objective reality and structure of Component-Bas...
Best Regards,
Raju Chiluvuri
Dear Mr. Song,
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
- Badges
- Science topic
- Similar topics
- Physical Sciences
- Materials Science
- Materials
- Inorganic Materials
- Metals
- Alloys
- Steel