Why Software Engineering & Computer Science ended up in Crisis

            Software researchers and Scientists forgot a simple scientific fact/rule: In real science, anything not proven is an assumption. When any scientific field is in infancy, researchers have no choice but to make few educated assumptions (e.g. first principles). The researchers and scientists rely on such assumptions for advancing makings knowledge. Unfortunately the scientific progress side-tracks and derails (i.e. end up in crisis sooner or later), if there are fundamental errors in the first principles (or assumptions) at the root of the scientific field.

It is essential to document the assumptions to avoid or minimize the harm caused by such first principles that are fundamentally flawed. Unfortunately computer science and software engineering has such fundamentally flawed assumptions at the root. It is not wrong to make assumptions 50 years ago (when software engineering was in infancy) and rely on such assumptions to advance our knowledge. But it is wrong and violation of scientific process/principles to rely on such undocumented or unknown assumptions.

I am sure thousands of researchers would have exposed such fundamentally flawed assumptions, if the assumptions at the root of software engineering were documented. For example, there are many baseless assumptions at the root of software engineering such as software components are different or unique. and it is impossible to invent software components that are equivalent to the physical functional components (by having essential properties uniquely and universally shared by each and every known physical functional component) for achieving real CBSD (CBD for software), where real CBSD is equivalent to the CBD (Component Based Design) of one-of-a-kind physical products (e.g. an experimental jet-fighter or prototype of a new kind of spacecraft).

For example, 500 years ago it was considered blasphemy to question validity of then undocumented assumption ‘the Earth is static’. Mankind relied on this undocumented assumption for centuries and created a complex paradoxical paradigm (i.e. altered perception of reality), and over the period this assumption at the root and the paradoxical paradigm deeply entrenched into the collective wisdom of mankind.

Today it is considered arrogant and disrespectful to question the validity of the definitions for so called software components and so called CBSD/CBSE. Mankind relied on such undocumented fundamentally flawed assumption for half-a-century and created a complex paradoxical paradigm (i.e. altered perception of reality), and over the period this assumption at the root and the paradoxical paradigm deeply entrenched into the collective wisdom of software researchers. Not documenting such untested assumptions is tantamount to considering them to be inalienable laws of nature, which would become impossible to question over time as they deeply entrenched into collective conventional wisdom. It might be impossible to even imagine invalidating such assumptions 50 years ago, but not documenting them is kind of like assuming that no one can ever find flaw in such untested assumption in million years.

Such untested assumptions must be documented in the first chapter books on software components and CBSD/CBSE, so that they will be always on the collective consciousness of students. Documenting such assumptions allow researchers to either validate or invalidate each assumption as and when mankind’s scientific advanced sufficiently. Since such assumptions are not documented, persons like me have to endure insults and disdain to even mention possible error. Is it really impossible to find real software components (e.g. for achieving real CBSD) even in a million years. If it is not impossible to invent such real software components, such assumptions must be documented, so that, future generations have a fighting chance (without facing insults and disdain) to invalidate such flawed assumption for putting the scientific and technological progress on right tracks.

If mankind were to acknowledge the possibility that, the Erath might be moving just like any other planets, I am sure, many researchers would have discovered that the Sun must be at the centre. After all, there are just 9 known planets including Moon (e.g. to test the hypothesis by putting each planet at the centre). But it was inconceivable 500 years ago the possibility that the Erath is moving around any other planet. I am sure anyone can discover real software components within weeks, if they acknowledge possible error and try to investigate truth. How complicated it is to discover the essential properties uniquely and universally shared by each and every known physical functional components? Based on my experience, it just takes couple of weeks. Unfortunately discovering the truth is not real problem, but the problem is questioning the validity of the flawed first principles (i.e. assumptions) at the root, which is real cause for any software field to end up in crisis. This struggle gave me unique perspective of why and how any scientific field end up in crisis (and how exposing the errors lead to scientific revolution by putting progress on right tracks).

Best Regards,

Raju

An irrefutable proof to show that the existing CBSD is a paradoxical paradigm resulted from relying on undocumented flawed assumptions.

In real science, anything not having proof (or not proven) is an assumption and such assumptions must be documented before relying on them to create definitions/concepts. Progress of any scientific discipline would be sidetracked into a wrong path and end up in a crisis, if there are errors in basic assumptions and if researchers relied on such erroneous assumptions for creating definitions or concepts and for advancing any scientific filed by relying on such definitions or concepts. No meaningful scientific progress is possible until the scientific progress is put on right path by exposing errors in such basic assumptions.

Why CBSD (Component Based Design) for software needs different and new description (i.e. definitions and/or essential properties) for software components and CBSD? These new and different description, properties, and concepts for so called software components and CBD for software products are in clear contradiction to the reality (i.e. facts, concepts and observations) we know about the physical functional components and CBD of large physical products (having at least a dozen physical functional components).

There exists no proof to show that any effort was ever made to discover reality about the physical functional component and CBD of physical products before creating the definitions and concepts for so called software components and concepts. The definitions and concepts at the root of existing CBSD (Component Based Design for Software) were made up out of thin air, without documenting the reasons or first principles (i.e. assumptions) that compelled to create such definitions and concepts that are in contradiction to the reality.

When I inquired for reasons, I heard many unsubstantiated assumptions, such as software is unique/different and/or it is impossible to invent real-software-components that are equivalent to the physical functional components (by discovering accurate description for the physical functional components and inventing real software components that satisfy the accurate description). In real science, anything not proven is an assumption and such assumptions must be documented before relying on them to create definitions/concepts. No text book for introducing software component or CBSE/CBSD listed such assumptions. No research paper or publication listed such assumption at the root of existing CBSD paradigm, which has been evolving for nearly 45 years by relying on such unsubstantiated definitions and concepts made out of thin air..

When any scientific discipline was in infancy, researchers are forced to make assumptions. For example, assumption "the Earth is flat" was a reasonable assumption 4 to 5 thousand years ago. Likewise, the assumption "the Earth is static" was a reasonable assumption 2000 years ago. But documenting such assumptions would avoid huge pain and suffering such as: http://real-software-components.com/forum_blogs/BriefSummaryOfTruths.html#Chronology. It is not hard to prove that, if the error at the root of geocentric model was not yet exposed, no meaningful scientific progress would have possible during past 500 years. As science and our knowledge expends, we can create tools to validate such assumptions, if they are documented and well-known.

All I am saying is, it is not wrong to make assumptions but it is wrong to not-knowing and forgetting (e.g. by not documenting) the assumptions at the root of our scientific knowledge, such as concepts and definitions for software components/CBSD. In real science, any thing that can’t be proved is an assumption. It is an error to rely on any such unproven assumption (without clearly documenting the assumptions) to derive concepts or definitions.

For discussion sake, let’s assume that the basic assumption was: “it is impossible to discover a set of essential properties uniquely and universally shared by each and every large physical functional component for inventing equivalent software components (having the essential properties)”.

This is highly falsifiable first principle (i.e. basic assumption at the root of software components and existing paradigm for CBSD), so it can be (and must be) proved false, if this basic assumption is flawed.

Likewise, if the assumption was: “it is impossible to invent a set of essential aspects uniquely and universally shared by each and every CBD of large physical product for achieving equivalent CBD for software products (having the essential aspects)”.

This is highly falsifiable first principle (i.e. assumption), so it can be proved false, if it is flawed. May be such assumptions could not be proved wrong (when such assumption was made and relied up on) 50 years ago, but they could be proved wrong when technology advances sufficiently for validating each such assumptions in the future (if such undocumented assumptions are flawed).

All I am saying is, it is wrong to NOT document such assumptions before relying on such assumptions for making up definitions for so called software components (out of thin air without any basic in reality, but based on wishful thinking). If there are errors in such undocumented first principles (i.e. basic assumptions), they sidetrack the scientific progress into a wrong path and scientific discipline end up in paradox.

If such assumptions were documented, I am sure 1000 researchers would have proved each of them wrong in past 50 years. But toady no one even know the assumptions to prove them wrong, if they are wrong. Such unsubstantiated assumptions were completely disappeared from our collective consciousness to even question their validity in light of technological and scientific advancements.

For example, this kind of assumption (i.e. it is impossible to discover such essential properties for the physical functional components) contradicts almost every thing mankind knows today. Let me define a universal rule: There exists an accurate description (e.g. a set of essential properties) for every known kind of a physical being or specie and the accurate description (e.g. a set of essential properties) can be used to positively identify each specimen belong to the being or specie. That is, the essential properties for any kind of physical being or specie can be used to positively determine weather a given specimen belongs to the physical being or specie.

Physical functional components can’t be an exception to this universal rule, since it is impossible to find any exception to this universal rule: It is possible to find an accurate description (e.g. essential properties) for each and every kind of a physical being or specie. Mankind’s scientific knowledge comprises accurate descriptions (e.g. essential properties) for millions of physical beings or species. There are millions examples to prove this universal rule, but impossible to find an exception to this universal rule (e.g. to falsify this rule). Every scientific discipline comprises accurate descriptions (e.g. often defined by a set of essential properties) for physical beings or species (to positively identify each specimen belong to respective kind of being or specie).

For example, isn’t essential for the field of zoology to acquire and accumulate the knowledge of accurate description for animals? Isn’t essential for the field of botany to acquire and accumulate the knowledge of accurate description for plants? The same is true for various sub-fields of microbiology such as virology, mycology, parasitology, and bacteriology. Likewise, accumulating knowledge of accurate description of atoms, molecules, compounds or elements is an essential for each sub-field of chemistry such as organic, inorganic or bio chemistry. No proof exists to show that the physical functional components are exception to this universal rule. It is impossible to find any one ever even tried to prove that the physical functional components are exception to this universal rule.

Once the set of essential properties uniquely and universally shared by each and every physical functional component is discovered, why is it not possible to invent equivalent software components having the essential properties? Although we can’t articulate the essential properties of the physical functional components, when any physical functional component is shown, it is not hard for any expert to positively identifying that it is a physical functional component. Likewise, it is not hard for any expert to positively identifying that it is not a physical functional component, if he is shown any other kind of physical part (that is not physical functional component).

This expertise of positively determine any given physical part whether it is a physical functional component or not a physical functional component, can be leveraged to discover essential properties uniquely and universally shared by each and every large physical functional component. Once the essential properties are discovered, it is a trivial task to invent real software components having the essential properties for achieving real CBSD, where the real CBSD must share the essential aspects uniquely and universally shared by each and every known CBD of large physical product (having at least a dozen physical functional components).

In fact, I can help any engineering expert or researcher to discover the essential properties uniquely and universally shared by each and every known large physical functional component. Likewise, I can help any engineering expert or researcher to discover the essential aspects uniquely and universally shared by CBD of any physical product (having at least a dozen physical functional components). It must not take more than couple of weeks to train any expert to gain this kind of expertise for positively identifying multiple real software components (equivalent to the physical functional components by having the essential properties) in any software application for achieving real CBSD (equivalent to the CBD of physical products by sharing the essential aspects).

Both teachers and books teaching concepts and definitions of so called software components and CBSE to impressionable students by forcing the students to learn definitions either to pass the exams or solve problems using the definitions and concepts. Without having proof, if it is right path or wrong path, we are pushing the impressionable students to well traveled (but wrong) path. Instead of teaching them (i.e. brain washing them),

We must ask impressionable students to investigate truth, instead of brainwashing then and pushing them into wrong path by teaching flawed definitions and concepts (derived by relying on undocumented assumptions). Please kindly read this interesting article, how reality can be distorted: https://www.psychologytoday.com/blog/pieces-mind/201208/few-the-many-ways-we-distort-reality. One can find so many examples that show, how reality can be distorted and end up in a paradox.

After graduation and gaining 10 years hands on experience on so called software components and CBSE (living in paradox of such distorted reality), obviously any CBSE expert thinks I am crazy (arrogant or disrespectful) for saying reality/facts such as, ideal CBD requires over 97% code must be implemented as CBD-structure (free from spaghetti code), but it is not necessary that even a single large component in the hierarchy need to have any properties we erroneously attributed to so called software components.

Why it is craziest thing to present facts, proof openly and requesting to investigate for discovering Truth?

If one says, he saw aliens or flying saucers from outer space, I am sure there are millions of people in the world believe him by giving him benefit of doubt. If any one says he has seen Elvis, Angle, Big-foot or Ghosts, I am sure there are millions of people believe him by giving him benefit of doubt. If he says he has proof and offer to show proof, many people and even press would show up to verify the Truth. Millions of people out there, who are willing to give benefit of doubt to even such craziest claims. For example, look at popularity of cults, fake gurus and terrorists dreaming of a place in the heaven by committing heinous acts against humanity and the God.

But no software researcher is willing to verify the truth (openly published in our website) that software parts equivalent to any other kind of physical parts such as ingredient parts (e.g. Cement, steel, plastic or silicon wafers) can’t be components for achieving real CBD for software. Just because each kind of parts needs complex process to create, is highly standardized and reusable across many product families, such parts can never be components and can never achieve CBD-structure (i.e. hierarchy of replaceable components).

How can I make them come out of their cult following of erroneous definitions for software components (made nearly 50 years ago and resultant paradoxical paradigm of software engineering) and investigate the simple facts for discovering the Truth?  Don’t they have any confidence in their own ability to reason and competency to verify simple facts for discovering the Truth? Where can I find such competent people who have confidence in their own ability to reason, intellect and competency to validate facts?

Let’s have some fun :-). What’s funny is, the USPTO granted multiple patents for our craziest inventions and ideas, which are treated (by most experts) less credible than sighting of Elvis or Ghosts. Many Silicon Valley investors boost that they prefer to invest in craziest idea or invention. If that is true, we have the craziest invention, which most experts feel crazier than sighting of Elvis or Ghosts. I am sure they can’t offer any proof to their crazy claims, but we put irrefutable proof (e.g. facts and reasoning) openly in our website for any one to investigate for discovering the Truth (but no one is willing to give us any benefit of doubt). If any one is willing to give us benefit of doubt, we are willing and delighted to demonstrate hundreds of real software components capable of achieving CBD structure. Unfortunately, Truth is snubbed even in the 21st century, so not much changed from the dark ages.

It is beyond my comprehension, that millions of people have no problem giving benefit of doubt to even craziest ideas, but why software experts stubbornly sticking to a lie and snubbing the Truth. I am sure even a layman can see the simple Truths, such as (i) no other kind of parts could achieve real CBD-structure (e.g. Hierarchy of Replaceable Components) and (ii) no design of a product can be CBD (Component Based Design), if the product doesn’t contain components and component hierarchies.

It is frustrating to here baseless excuses to rationalize obvious contradictions (i.e. in existing paradox of CBSE) and refusing to provide any support to such baseless excuses. What happened to commonsense and reason? Why are they obsessed with reusable components (- a complex fiction) but choosing to be ignorant about simpler realistic goals such as achieving hierarchy of replaceable components? If software researchers chose to achieve hierarchy of replaceable components for large software applications, I am sure, software industry could achieve that goal in couple of years.

I do not feel obliged to believe that the same God who has endowed us with sense, reason and intellect has intended us to forgo their use 
-- Galileo Galilei

P.S: If heaven and hell exist, it must be a pleasure to see the look on the face of each of the terrorists (dreaming of heaven) when he is told (after his suicide mission) that he is doomed to hell for his heinous acts against humanity and the God (by blindly following cult leaders without using his ability to reason, which is endowed to mankind by the God).

I do believe in the God (I choose to have this blind faith - my personal subjective choice since many years), because this faith gives me some peace of mind during bad times. I am absolutely sure that the God gave me sense, reason and intellect to not forgo their use. I rarely bother the God (by praying :-) him) when I have no problems.

Brief Summary of Truths for Real Components & Real CBD

Truth-1: There exists a set of essential properties uniquely and universally share by each and every known physical functional component. That is, it is impossible to find a physical functional component without having the essential properties. No physical part can be a component without having the essential properties. These essential properties can be discovered (i.e. factual and unambiguous objective answer to the 2nd question in the preamble at the top of our web site).

It is possible to invent equivalent (i.e. real) software components that are having all the essential properties (or characteristics). Hence it is a flaw (or error) to define any other kind of software parts is a kind of software components – Existing software engineering paradigm and so called CBSE (Component Based Software Engineering) has been evolving since mid 1960s by relying on this kind of flawed (and baseless untested) definitions for so called software components.

Truth-2: Likewise, there exists a set of essential aspects uniquely and universally share by each and every known CBD (Component-Based Design) of one-of-a-kind physical product (e.g. prototype of a spacecraft or experimental jet-fighters). The essential aspects can be discovered (i.e. factual and unambiguous objective answer to the 1st question). So, similar reasoning can be used to define that real-CBSD (Component Based Design for Software) must satisfy the essential aspects.

We can tie these 2 individual (or independent) discoveries to complement and support (or prove) each other. The fact is, except physical components, no other kind of parts can achieve real CBD. Hence, no other kind of so called software components (not having the essential properties), except real software components (having the essential properties) could be able to achieve real-CBSD (by satisfying the essential aspects of CBD, such as, containing hierarchy of replaceable components).

The real software components and real-CBSD are two mutually independent discoveries that complement and support each other. For example, Kepler’s laws were extremely useful not only to make but also to support Newton’s discovery of Gravity. The discovery of gravity provided sound scientific explanation for Kepler’s laws. So Gravity and Kepler’s laws are mutually independent (i.e. stand-alone or individual) discoveries that complemented and supported (e.g. proved) each other.

Of course, each of the individual discoveries was independently supported by reality (i.e. facts, observations and empirical evidence) and/or impeccable reasoning (e.g. mathematical calculations). Likewise, real software components and real-CBSD are individually supported by reality/facts and impeccable reasoning (in this web-site). Furthermore they compliment and support (e.g. prove) each other, which is another compelling additional confirmation or supplementary proof.

The three layers (i.e. science, engineering and art) for invention and innovation of each of the products.

The progress of pure science is discovering new truths (or irrefutable facts) for expanding the boundaries of human knowledge. The scientific research is nothing but pursuit of absolute truth. The scientific foundation comprises of irrefutable scientific facts/truths, and well tested/proven theories/concepts created by using sound reasoning, logic, which are further supported by empirical evidence (e.g. repeatable experiments). The scientists propose falsifiable hypotheses and each of the hypotheses is tested against whole world of known/recorded facts, observations to falsify the hypothesis. Any falsifiable theory/concept is not false, but it can be falsified, if it has flaw. Any hypothesis is eventually accepted as a proven theory or concept, when no flaw can be found.

The pure engineering is inventing (and/or innovating) useful things (e.g. parts, and engineering infrastructure such as tools, processes, models) by relying on the sound scientific foundation. The components such as internal combustion engine, Jet-engine, CPU, DRAM or parts for fiber optic networks are pure engineering inventions. Likewise, ingredient parts such as steel, plastic, gasoline, cement, battery-parts and metals or alloys) are pure engineering inventions. These kinds of things are continuously optimizer for sheer engineering perfection, performance and precision. So such things begin as pure engineering inventions and continuously evolved by mostly pure engineering innovations.

Even an ugly looking compact internal combustion engine looks beautify and gains admiration, if it is two times more fuel efficient at lower price. No one cares the looks of CPU, DRAM or parts for fiber optic networks, if they are 2-times better than nearest competition in tangible aspects such as price & performance. The research effort and process for inventing or innovating each of the engineering things must rely on a set of scientific facts or concepts, and the research effort would fail, if there are flaws in the scientific facts and concepts.

These kinds of engineering things are used to create products used by human beings (e.g. consumer products or products that are used by engineers). The architects and designers of such products employ engineering and art (e.g. to suite taste or preferences of target users) to innovate user friendly products (e.g. Cell-phones, PCs, TVs, iPod, Twitter, Whatsapp or Facebook etc.), by relying on the things invented and innovated by employing pure engineering (where the engineering progress was possible only due to relying on sound scientific foundation). Although only the art is visible and makes competitive deference in consumer products such as iPhone or Facebook, there is lot of invisible science and engineering goes into each of the products.

Steve Jobs and Mark Zuckerberg are Steven Spielberg’s of technology industry – Great story tellers - know what users or consumers want better than the consumers themselves. There could be dozens of companies who has engineering capability to build products such as iPhone or Facebook, but can’t deliver on artistic taste (or creativity) and understanding of consumer intuition (or fascination). They have great intuition, taste or charisma to capture our imagination/fantasy. All the other competing companies have access to same engineering and scientific knowledge, the inventors and innovators of consumer products succeed by heavily relying on intangible artistic taste and creativity for differentiating from competition. Even if they encounter few technological shortcomings to achieve envisioned perfection, I am sure most other competing companies could overcome the shortcomings (if confronted with the same technological shortcomings).

My objectives: (1) expanding boundaries of mankind's scientific knowledge by discovering unknown facts about the physical functional components and CBD for physical products, and doing engineering research (by leveraging the existing and newly discovered scientific facts) (2) to invent new useful things such as new kind of component models and processes, and (3) inventing basic missing pieces for software engineers such as CASE-tools & reusable libraries.

Each of the successful products used by mankind is blend of the three ingredients (i) scientific discoveries, (ii) engineering inventions and (iii) art (artistic imagination) or taste (tasteful design). In the layer-1 (scientific research), absolutely there is no room for subjectivity. In the layer-2 (scientific research), there may be room for small percent of subjectivity. The joy of pure engineering is creating best algorithms such as compression, clustering and encryption or decryption, which are tangible and can be measured against alternative inventions in key performance aspects. In the layer-3 (research for products such as tools and libraries for engineers) there is lot of room for intangible subjectivity and artistic creativity (e.g. each set of consumers might like a different version of the same product invention). There could be multiple winners, since there is a room for subjectivity.

Each of the successful products used by mankind is blend of the three ingredients (i) scientific discoveries, (ii) engineering inventions and (iii) art (artistic imagination) or taste (tasteful design). One must be clear in which layer (i.e. ingredient) one is focusing, when one is doing research. Likewise, one must be clear which layer is the contest, if one is discussing or debating. In the layer-1, goal is to discover the facts that are closer to absolute truth (e.g. compared to competition). One can invent (or innovate) better engineering things by relying on better facts. In layer-3, there is lot of room for subjectivity, so whoever predicts the user taste/needs (e.g. by fulfilling user imagination/fascinations) wins.

The inventions & innovations of engineering (i.e. layer-2) can be expanded by expanding the boundaries human knowledge in layer-1, for example, by discovering new scientific facts. The expansions of layer-2 allow expansion of layer-3, for example, resulting in inventions of new products and innovations in existing products. The scientific and engineering progress would certainly derails and end up in crisis, if there are errors in mankind’s knowledge in layer-1. That is, expanding the layer-1 leads to expanding layer-2 (invention of new things and drastic improvements to the performance of existing things), and expanding the layer-2 leads to expanding the layer-3 (i.e. invention of new kind of products and drastic improvements to existing products).

There are huge gaps in the layer-1 (i.e. in computer science) such as fundamental flaws in the basic axioms and concepts that are foundation for existing software engineering paradigm. The software engineering ended up in crisis because it has been evolving for nearly 5 decades by relying on such flawed concepts (by assuming them to be facts). These flaws are buried deeply under a thick layer of hundreds of books and thousands of research articles published world over spanning 50 years and made invisible by resulted distortion of reality and a complex paradoxical paradigm.

How could mankind invent computer chips by being clueless about the essential properties of electrons, such as how they behave in semi-conductor material? How could mankind invent fiber-optic networks by being clueless about essential properties of light, such as how it behaves in strands of optical-fibers? Likewise, mankind can’t invent real CBD for software by being clueless about essential properties of physical components and essential aspects of real CBD for the physical products, since the essential properties enable the components to achieve the real CBD having the essential aspects (e.g. 0% spaghetti code).

The order of product creation is (i) discovering the scientific reality and facts, (ii) use the knowledge of the facts and reality to make engineering inventions, and (iii) The products are created by using the engineering knowledge and expertise. But computer science defined the nature of components (and aspects of CBD for software) without any basis in reality (or fact), and researchers of software engineering have been trying to invent CBD for software for nearly half-a-decade by relying on erroneous scientific foundation. Trying to invent engineering before science is like putting cart before horse - it never works. This passionate effort of thousands of researchers spanning over 50 years resulted in evolution of a complex paradoxical paradigm. This is no different from trying to advance the scientific knowledge for 1000 years, by relying on the erroneous fact that the Earth is static at the center, which resulted in evolution of a paradoxical paradigm that was so complex that even saying the truth “the Sun is at the center” 500 years ago offended the common sense and insulted the deeply entrenched conventional wisdom (of then prevailing geocentric paradigm).

My request is just discover the scientific truths (E.g. essential aspects of real CBD of physical products and the essential properties of physical functional components that are enabling them to achieve the real CBD of physical products). Then rely on the scientific foundation (of truths) to invent equivalent real software components for achieving real CBSD (CBD for Software) having the essential aspects. Each of the definitions for each of the kinds of software components known today has no basis in reality, so it is a huge violation of scientific process to blindly rely on such software components for inventing CBSD.

Is it possible to discover innate nature and essential characteristics uniquely and universally shared by all the physical functional components?

Dear Friends,

I believe the answer to above question is Yes! If researchers of computer science try to discover the innate nature and essential characteristics uniquely and universally shared by each and every known physical functional component, I can’t find any valid reason why the researchers could fail. The last several paragraphs are dedicated to support this answer (please let me know, if there is any flaw).

If the answer is Yes, why is it not possible to invent equivalent software components sharing the innate nature and the essential characteristics?

Let me define what is meant by essential characteristics: The essential characteristics are the minimum set of properties uniquely and universally shared by each and every known physical functional component. That is, if ‘X’ is an essential property, no physical functional part can be a functional component without having the property ‘X’, and the physical functional component could no longer be a physical component, as soon as it looses the property ‘X’.

In software applications, we only deal with functional components and larger components are more useful, so as a first step I am only interested in discovering such essential characteristics of the physical functional components. This also eliminates possible conflicts and confusion in case of border or fringe cases and non-functional parts such as bolts, nuts, washers and other individual pieces of metal (e.g. panels for car such as bumper, bonnet or grill), plastic or glass (e.g. windshield glass or mirror). Of course, a functional component such as auto-engine may be created by assembling multiple pieces or parts of metal.

Let me provide background for how and why I started this research effort:

I accidentally stumbled onto a GUI library that is capable of implementing a class definition by encapsulating the application code for any GUI-application (where the class definition is referred to as RCC-Replaceable Component Class). These RCCs can be used to assemble these applications as sub-components to build larger and larger RCCs (for building larger and larger container-components). In this case, it required just 3 lines to assemble each replaceable component by using respective RCC, and the component can be effectively removed by removing the 3 lines. For example, this sample application is created by 6 such RCCs: http://real-software-components.com/CBD/City_GIS.html

After implementing application code for many small GUI-applications as RCCs, it was fascinating to see even junior developers able to build complex GUI-applications having hierarchy of replaceable components by using each of the RCCs to assemble each of the replaceable components. It induced irresistible curiosity more than 10 years ago and decided to focus on this research. Another thing, I felt (after creating hundreds of hierarchies of replaceable components) that the replaceable components are equivalent to the ideal physical functional components and each of the hierarchy of replaceable components is logically equivalent to the CBD-structure (one of the essential aspects of the CBD design of physical products). See CBD-structure: http://real-software-components.com/CBD/CBD-structure.html

This kind of experiments made me consider the possibility that it is possible to invent real components for software that are equivalent to physical functional components for achieving real CBD for software (e.g. by achieving a structure equivalent to the CBD-structure for any software application).

After careful observation of many large physical functional components, I believed, there exists a mysterious property that is uniquely and universally shared by each and every known physical functional component. I could not find any terminology to describe the mysterious property. After further research and making satisfactory progress and beginning to grasp the innate nature, I named the mysterious property ‘self-contained’, since I felt that the term “self-contained” roughly (or vaguely) fits the intended meaning of the mysterious property.

So I created a hypothesis that each and every physical functional component shares an essential property, which I named “self-contained”. I must validate this hypothesis for discovering the nature by employing a scientific process. I used the following method (which I believe is a widely used proven scientific method) to discover the intended meaning of term “self-contained”: http://real-software-components.com/RSCC/accurate_description_for_CP.html

I believe, any software expert can discover the intended meaning of ‘self-contained”, but it is not a simple task to discover the innate nature and the essential characteristics of the physical functional components. If this task is simple, software engineering would not be in this mess. For example, existing software engineering paradigm has been evolving for decades by relying on an erroneous postulation (or axiom or hypothesis), which defined the term ‘software components’ as an alias to ‘software parts’ either having useful properties (e.g. reuse or standardized etc.) or conform to so called component models. I believe, this task to discover is not impossible either. I believe, it requires few weeks of intense experimentation, critical analysis of facts and focused mind exercises or critical thinking (e.g. to overcome conformation bias, perceptions and basic concepts of deeply entrenched existing paradigm) to achieve gestalt’s shift.

Each large software application comprises of multiple ‘self-contained’ parts or modules. Since the essential property of ideal functional components is not yet discovered, today the chief software architects and designers of large software applications are not putting any conscious effort to identifying ‘self-contained’ parts or modules exist in the applications. I am proposing a new kind of CBD (Component Based Design) that requires identifying the multiple ‘self-contained’ parts or modules and implement the application code for each of the ‘self-contained’ parts or modules as an RCC (Replaceable Component Classes).

Each of the RCCs must require no more than 3 to 5 lines of code to assemble the respective replaceable component, and one must be able to effectively remove this replaceable component by removing the said 3 to 5 lines. It is preferable to not implement any more code for communication or configure each of the object instances of RCCs (i.e. replaceable components), so each replaceable components must rely on an intelligent CASE tool to collaborate with other components or parts of the container application. A internal implementation of a sample intelligent CASE tool is illustrated in FIG-3 at: http://real-software-components.com/CBD/Sample_SoA_CASE_tool.html

Therefore, the essential pre-requisite for the proposed CBSD (Component Based Design for Software) is discovering the essential properties of ideal functional components (of the physical world) to positively identify equivalent components in the context of software applications (a virtual world). That is, if the essential property is ‘self-contained’ (as I proposed), the software designer of an application must discover the intended meaning of the term ‘self-contained’ for positively identifying large self-contained parts in his software applications.

The primary differences between existing software design and proposed design for any large software application is: The chief designer must discover the essential properties (e.g. intended meaning of term ‘self-contained’) for positively identifying multiple ‘self-contained’ parts or modules. Implement each of the ‘self-contained’ parts or modules as a RCC, where each of the RCCs must rely on an instance of intelligent CASE-tool (included in the application by using a reusable class) for collaborating with other components and parts of the application.

It is not hard to implement a reusable class for the intelligent CASE-tool that can maintain coupling-interfaces of each of the components and facilitate communication between any two components by couplings the interfaces of components. Once a ‘self-contained’ part or module is identified, it is not hard to implement the application code in a set of exclusive files associated with a class definition referred to as RCC (in any modern Object-oriented programming languages such as C++, Java or C#).

In case of GUI-applications, the task of identifying self-contained parts or modules is less complex. In case of non-GUI-applications, the task of identifying self-contained components is more complex. That is, it requires lot more practice, knowledge and expertise not only on the innate nature of the component but also respective domains of non-GUI-applications.

However there is a catch-22 situation: In case of GUI-application, even though it is less complex to identify self-contained parts or modules, but no other GUI library (e.g. Windows/VC++ or Java/Swing) are designed to encapsulate application code of a self-contained component (e.g. a small GUI-application) such as City_LandMarks in a class definition. I am only saying that capability doesn’t exist in each of those GUI libraries (because the vendors of respective GUI platforms haven’t even heard of replaceable components). I am sure vendors of respective GUI platforms can quickly implement that capability, if they want to (e.g. if they discover the replaceable components and believe such RCCs are useful).

The most complex part for achieving real CBSD (Component Based Design for Software) is discovering the intended meaning of the term “self-contained”. Discovering the nature help the chief-designer to identify various parts and functionality or features of the applications that can be implemented as RCCs (Replaceable Component Classes).

Therefore, the trillion dollar question is: Is it possible to discover the nature and essential characteristics of ideal physical functional parts? I believe, the answer is absolutely YES! I am not saying it is easy to make this discovery. I am only saying that it is not impossible. I can’t give elaborate argument here, but let me give a simple argument (I am hopping smart people can connect the dots and fill any gaps or missing pieces). Also I appreciate finding any flaws or shortcomings to oppose (e.g. cons) or in support (e.g. pros) of the following argument.

Theoretically it is possible to discover nature (i.e. essential properties) of any physical being, including components. If attempted to discover the innate nature and essential characteristics, mankind never failed to discover the essential characteristics of any physical beings which can be seen and touched. A big part of basic sciences (e.g. chemistry, botany, zoology and physics) is to discover the nature (e.g. essential characteristics) of physical beings and (e.g. essential aspects of) phenomenon. Of course, mankind already discovered innate nature and essential characteristics of more complex and diverse species such as mammals, animals, plants, elements, atoms, molecules and bacteria etc.

Unfortunately it is impossible to find any evidence that researchers of computer science ever tried to discover the innate nature and essential characteristics of good old physical functional components (i.e. certainly a physical being) or essential aspects of good old CBD for physical products (i.e. logically a physical phenomenon). Without even trying and not even contemplating, is it wise to assume or argue that it is impossible to discover the innate nature and essential characteristics of good old physical functional components (i.e. certainly a physical being) or essential aspects of good old CBD for physical products (i.e. logically a physical phenomenon).

Let me name one of the exceptions that prove the rule: Scientists not yet successful in discovering the internal structure and nature of electrons, protons and neutrons (that are certainly physical beings), for which the scientists have been using string-theory to make this discovery. An example for a phenomenon the scientists not yet successful in discovering is origin of universe, for which the scientists are using theories such as big-bang-theory. It is very hard to find such rare exceptions. No one disputes the fact that, the right answer must be an objective Truth (if it is ever discovered). Although some experts might argue that it is impossible to discover the internal structure of sub-atomic particles, but all agree that there must exist a unique answer and the answer is an objective Truth. That is, no one disputes the very existence of an objective truth, only express doubt about mankind’s ability to discover the truth any time soon.

Hence there exists an objective Truth for the essential characteristics and nature of any kind of physical being including for ideal physical functional components. I can’t find any valid reason, why mankind can’t discover the objective Truth. We can’t see internal functioning of sub-atomic particles, but we can see internal functioning of ideal physical functional components. When tried, mankind never failed to discover the essential characteristics and nature of any physical being, even if they are 10 times more complex than physical functional components. Hence, there is no valid reason, why it is not possible discover the essential characteristics of physical functional components, if researchers of computer scientists try to discover innate nature of ideal functional components.

If an alien send to the Earth to find an elephant, the pre-requisite to successfully accomplish this task the alien must discover or know accurate description to positively identify the elephants. Likewise, designer of a software application must know or discover the accurate description (i.e. objective facts about the essential properties) of ideal functional components (in the physical world, in the context of the application domain) to positively identify equivalent software components (of virtual world – an alien landscape) in the applications.

Sorry for a long background and summary for the above question. If I am right, correct answer to this question would have profound impact on the progress of software engineering. I believe it is possible discover the essential characteristics of physical functional components. Also I believe it is possible to invent real components for software by having the essential characteristics.

The exiting software engineering paradigm has been evolving for several decades by relying on these untested premises (postulations or hypotheses), which are: Today each kind of software components is nothing but a kind of software part (or module) either having given useful properties (e.g. reusable or standardized etc.) or conform to a so called component model. Using one or more kinds of such so called software components is defined as a kind of CBSE or CBSD (Component Based Design for Software).

If it is possible to discover the essential properties and when the essential properties are discovered, the discovery not only exposes errors in above postulations (or untested premises or hypotheses) that sidetracked progress of software engineering for decades but also puts back the progress of software engineering on right tracks by allowing us to invent real components for software (for achieving real CBD for software, since logically real-CBD for software requires using real components for software).

P.S: This is posted at: https://www.researchgate.net/post/Is_it_possible_to_discover_innate_nature_and_essential_characteristics_uniquely_and_universally_shared_by_all_the_physical_functional_components#share

Best Regards,

Raju Chiluvuri

Most software experts lost their ability to grasp even simple facts, because they are brainwashed and deeply indoctrinated into existing paradoxical paradigm for over 40 years.

            Please kindly allow me to briefly explain basic facts about an ideal Component-Based Design (CBD): If a physical product has 100 functional components, each functional component can be designed and build individually by an engineer as best as it can be. Then each component can be plugged-into container component (or product) to build the product. For example, in case of a computing device, the components can be designed to plug-into a bare PCB (Printed Circuit Board).  For example, please refer to CBD-structure for logical structure of physical functional components.

            If any component doesn’t fit or function as expected, the component can be unplugged and refined individually little-by-little (can be tested by plugging-in) to make sure it fits properly and functions as required within the product. This process is repeated for each of the components (by the designers of the component individually) until all the components and the resultant product functions as required. The essential nature of any functional component is: The component is fully constructed by the engineers building each of the functional components and the engineers using the physical functional component (e.g. as a component or as a sub-component of another component) can just plug-in the component without any construction and with little or no configuration.

Of course, most of the useful products must be evolved for many decades by releasing better or improved models. The above product is evolved by evolving each of the components individually (e.g. by adding more and more functionally and/or features to each component). Also the product can be evolved by adding more new components for providing more functionality and/or features. Please refer to CBD-process.

            The above are the simple and obvious facts of CBD for physical products. That is, engineers of each component must be able to design, built and test their component individually. It is not necessary for the engineers of any component to see internal design any other components. In case of ideal-CBD, when all the components are unplugged (one component at a time), the product left with an empty PCB. Therefore, the ideal CBD achieves highest degree of modularization theoretically possible. It is not necessary that even a single component in the component-hierarchy to possess any properties (e.g. reuse, standardized or conform to any so called component models) erroneously attributed to so called software components known today.

            Of course, many software experts have no problem understanding the above ideal-CBD in the context of designing and building physical product such as an experimental super-computer. They have no problem accepting the facts that: It is not necessary that even a single component in the component-hierarchy to possess any properties (e.g. reuse, standardized or conform to any so called component models) erroneously attributed to so called software components known today.

They have no problem accepting the above simple facts of an ideal-CBD. But they would never accept these facts and nature in the context of software components and CBD for software. Many experts so deeply indoctrinated and brainwashed into existing paradoxical paradigm, they loose their ability to even see the above simple truths in the context of CBD of software products and software-components.

My research goal is to define an ideal-CBD for software products and achieve such ideal-CBD for software products, which must be equivalent to the ideal CBD for physical products. My research effort found a way for achieving this goal. This goal can be accomplished by using real-software-components equivalent to the physical functional components (where the real-software-components share essential properties uniquely and universally shared by each and every physical functional component).

That is, building software applications by taking a generic application template and plugging-in all the real-software-components. In case of ideal-CBD for software, each of the real-software-components must require no more than 3 to 5 lines of code to plug-in the real-software-component (even if the component has dozens of large sub-components). Furthermore, removing these 3 to 5 lines of code must effectively remove the real-software-component (without leaving any traces). The application must be left with generic application template, when all the software-components are unplugged (by unplugging one component at a time).

Unfortunately, software experts fail to grasp the simple fact about the real-components: The builders of each of the physical functional-component can only focus on the internal design of just one physical functional-component without any distractions, since it is not necessary for them to see internal design of any other component (not only during initial model for first release but also for each of the successive models throughout the evolutionary life) of the product.

In case of software, it is not necessary for any engineer responsible for either implementing a component for first release or evolving by improving a component (i.e. RCC) for successive models to see even a single line of code implemented for any other component in the software application. Another essential requirement of a real-software-component is that the component must be unplugged effectively by removing 3 to 5 lines (even if has hundred sub-components). Only real-software-components can satisfy the second requirement, because reusable GUI-classes for GUI-components satisfy the first condition but can’t satisfy the second condition, because one must implement many lines of application code not only for accessing and processing the application data but also for using the data to construct and configure the instantiated GUI-object to assemble a GUI-component in an application.

Let me define 2 essential conditions for real-software-components (or ideal physical functional components) are: (i) The designers or engineers of any component must be able to focus on code-base of just one component without being distracted, for example they should never see even a single line of code implemented for any other component (not only during initial model for first release but also for each of the successive models throughout the evolutionary life) of the product. (ii) One must be able to plug-in each of the real-software-components by implementing just about 3 lines of code and one must be able to effectively unplug the component by removing the 3 lines. That is, no real-software-component requires implementing any more associated code, for example, either to construct or configure the component.  It is desirable to eliminate necessity of implementing even communication code by using intelligent CASE-tools.

The so called software component known today breaks the second condition. For example, reusable components (e.g. GUI-classes for presenting GUI-components such as Pie, Line or Bar charts) satisfy the first condition, but can’t satisfy the second condition. In general, the real-software-components are custom designed to satisfy unique needs of target application (so can encapsulate or packaged all the application logic in a replaceable container/package that can be plugged-in and unplugged) and self-contained, so requires little or no application code (e.g. for construction and configuration etc.) after plugging into its target product. This second condition is extremely important distinction between real-software-components and other kinds of so called software-components known today.

For example, kindly review a sample City_GIS application that is build by plugging-in just 6 large functional components. Of course, large applications might contain 100s to 1000s of such plug-in components. Since the real-software-components are custom designed to satisfy unique needs of target application, it is possible to design and build larger and larger real-software-components as plug-in components (that needs just 2 or 3 lines to disassemble or re-assemble) as illustrated by CityLandMarks (having 3 sub-components). It is not practical to design CityLandMarks to be reusable in multiple applications, because to make such components reusable, each component must be designed to be context-independent and must be configurable to context of each application (which requires implementing code for using application specific data).

Furthermore, nearly 100% of the application code for any application (e.g. City_GIS) can be implemented as real-software-components. The real-CBSD could eliminate 100% of the spaghetti code, since designers of each real-software-component can focus only code base of just one real-software-component (without being distracted by even single line of spaghetti code implemented for any other component in the application).

Each and every known physical functional-components satisfy two important conditions outlined for real-software-components above. Therefore, over 90% of the functionality and features of any complex physical product can be implemented in physical functional-components. Each engineering team can work on each of the functional components individually (without being distracted by noise or spaghetti code), even if the product has 1000s or tens of 1000s of functional components.

The manthra of real CBD for physical products is: Allow the designers of each functional-component to focus on internal design of the component, by eliminating 100% of noise or interference (by shielding them from exposing internal design of any other component). The manthra of real CBD for software products is: Elimination of 100% of the spaghetti code from the application, by partitioning all the functionality and features of any large application into hierarchy of real-software-components.

Partitioning any complex product into hierarchy of replaceable components eliminates huge accidental complexity and allows engineers to just focus on essential complexity. In case of complex software today, nearly 80% of the efforts of software engineers are wasted on accidental complexity. The real-software-components can be invented for achieving ideal CBD for software by discovering essential characteristics uniquely and universally shared by each and every physical functional component. The discovery of essential characteristics also helps experts realize that they were brainwashed and indoctrinated into existing paradoxical paradigm.