Sunday, November 2, 2014

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.


Sunday, October 26, 2014

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.


Friday, September 12, 2014

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.

Monday, April 14, 2014

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).
Best Regards,
Raju Chiluvuri

Thursday, February 27, 2014

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.

Wednesday, January 22, 2014

Urging software researchers to discover real-CBSD and set the goal to achieve real-CBSD for large and complex software products


Toady CBSD (Component-Based Software Design) or CBSE (Component-Based Software Engineering) is defined as using so called software components. It is not much different from defining flying is not much more than flapping wings, by alien species who have not yet discover ‘what is real flying’. Why is it not possible to discover the beauty and grace of real flying by observing aerobatic maneuvers of majestic birds (e.g. Peregrine Falcon, Golden Eagle etc.) chasing a prey or modern Jet-fighters in a dogfight (e.g. by watching videos)? Likewise, Why is it not possible to discover the beauty and grace of ideal-CBD and ideal-CBE (by investigating and analyzing all the facts to discover essential aspects uniquely and universally shared by the design of each and every complex physical product built by assembling physical components)?

Please let me describe an ideal CBD, since I believe it is possible to achieve the ideal CBD for designing and building complex software products. An ideal CBD of any complex product requires partitioning the product into hierarchy of replaceable components, where the term replaceable means that the component can be easily disassembled and reassembled as a unit. The FIG-2 in CBD-structure illustrates a logical structure of the components, where even a container component can be unplugged as a unit and disassembling the container component effective removes all it subcomponents from the product without leaving any traces. It is important to comprehend and always keep in mind the 3-CBD-facts and 3-CBD-rules.

In an ideal CBD, no component must take more than few minutes for disassembling by unplugging the component and must not take more than few minutes for reassembling by plugging-in the component. In ideal CBD, one must left with bare board (e.g. PCB board having holes to plug-in pins of each component), if all the components are unplugged (by unplugging one component at a time). In general, a team of engineers build each of the large and complex products, where each engineer is responsible for designing and building one or more components in the hierarchy of the replaceable components.

In case of ideal-CBD, no component should be too complex to require effort of more than one engineer. Each component should be of optimal complexity and allow each engineer to work in a manner consistent with his skills, expertise and talent. It is useful to define an optimal complexity, for example, an average newly recruited engineer should need no more than couple of weeks to grasp the design of a large component to safely make simple changes (e.g. to add simple features and functionality).

Each component can be designed developed and tested independently outside of the product. Once satisfied with its quality and functionality, the stable version of the component can be assembled into the product to make sure it performs as expected in the product. Furthermore the component can be refined little-by-little until it performs optimally within the products (e.g. by perfectly collaborating with other components), which results in yet another stable version of the component.

This stable version of the component can be refined and tested independently outside of the product for adding more features or functionality for creating yet another stable version of the component. This version of the component can be assembled into the product to make sure it performs as expected in the product. Furthermore the component can be refined little-by-little until it performs optimally within the products (e.g. by perfectly collaborating with other components), which results in yet another stable version of the component.

For example, the sample City_GIS application achieved the ideal-CBD (Please also refer to important FIG-3). A source code control system SCCS or RCS/CVS can be and must be used for tracking the code base of each of the components, so that it is possible to restore any of the older versions of the components. For example, if an engineer wishes to experiment by adding few features he feel useful and creates a new version, but only 40% of the customers liked it, he could restore the older version. For example, a junior engineer joined and need to add few more features and in the process the code base of the component is ended up sub-optimally by the time he gained enough experience in the domain, he could restore older version and restart again.

In case of real-CBD, each component have exclusive blueprint (e.g.code-base) than can be versioned and sandboxed. Hence no engineer can damage design (e.g. code base or blueprint) of any other component. But in case of software, even a simple application having just three large components begin its life as spaghetti code. That is, each file contains code-sections for more than one component, so finding and redesigning code sections of any component is a complex task. Then to test the component, one must test whole system. If one wishes to restore older version, he must restore the all the files (which result in loosing changes made to other components during this period in those files).

Some of the benefits of real-CBD include: Each component can be optimized (e.g. re-factored) and tested independently. More than one version can be maintained for each component, to address different segments of customers. The real-components are often by nature neither reusable nor standardized, since each of the components are custom designed to optimally satisfy unique needs of its target application (and also must be adoptable to unpredictable evolving unique needs of its target application).

However, if another new product-model requires similar component, the blueprint (e.g. code base) of an existing component can be redesigned to create a customer version for the new product-model. Hence real-software-components offer excellent knowledge and code-base reuse. Today, it is not practical to reuse the knowledge and code-base, since the code-sections of large software components are spread across many non-exclusive files, where the files comprise code-sections for multiple components.  We invented a GUI-API, which allow encapsulation of any complex GUI-component is a class definition, which makes the component not only replaceable but also code-base for the GUI-component can be encapsulated in an exclusive set of files for versioning and sandboxing.

The above kind of GUI-API is one of the essential missing pieces for inventing real-CBSD. Other inventions essential for real-CBSD/CBSE include: An ideal CBSD/CBSE requires employing intelligent CASE-tools that must automate creation and management of communication code by managing coupling interfaces of each component for automatically detecting any incompatibilities between coupling interfaces of any two components.

After creating hundreds of component-hierarchies (many of them I am more than eager to demonstrate to fellow researchers), I can’t find any valid reason why designers of complex software products can’t achieve CBD-structure for most of the large and complex products. I strongly request software researchers to discover essential aspects uniquely and universally shared by design of each and every large CBD-product for discovering inherent nature of real-CBD; and discover essential properties uniquely and universally shared by each and every large functional-component for discovering inherent nature the functional-component.


Unfortunately substantial research effort has been wasted in past three decades for chasing goals that are not much less than science fiction by relying on baseless axiomatic postulations (which are not much less than myths). For example, a goal chosen in formative years during mid 1960s of software engineering was: building software as we build computers by assembling reusable components from third party vendors. Even a quick analysis of obvious facts and simple observations conclusively prove that it is impossible to achieve such a fantasy.