Friday, December 26, 2014

Proposing a new scientific discipline in computer science: Componentalogy


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.

Mankind’s scientific knowledge in each of the scientific disciplines is kind of like a large picture drawn on a huge canvas, where the picture comprising numerous small parts/pieces representing our perception of reality. Each small part of the picture represents a piece of knowledge/fact, where most parts/pieces are clearly visible, while few are blurred (out of focus) & others are hardly visible. The goals of each scientific discipline is to acquire and accumulate pieces/parts of knowledge of facts for painting increasingly clearer picture (i.e. evolving our perception of realty closer and closer to absolute truth/true-reality), for example, by finding more accurate facts of description or nature of various specimens and species, which includes clearly documenting flawless knowledge for recognizing finer differences in each part/piece like best discriminating connoisseurs.

It is foolish to define the nature of planets without any basis in reality and expect nature to change its course to fit the baseless definitions. Likewise, acquire and accumulate the knowledge of accurate description for component/CBD is essential for researchers of components/CBD. It is foolish to define the nature of component without any basis in reality and expect nature to change its course to fit the baseless definitions. It is huge error to assume and use the term components as a synonym to parts either having certain useful properties (e.g. reusable or standardized) or conforming to, so called component models (where each component model is defined without any basis in reality).

I believe biology, zoology or scientific discipline of microbiology such as virology, mycology, parasitology, and bacteriology are at least 25 to even up to 100 times complex than Componentalogy - a new scientific discipline proposed in computer science. The purpose of Componentalogy is acquiring & accumulating flawless pieces of knowledge of scientific facts by painting/re-painting each piece/part of the image for increasing the clarity and evolving increasingly clearer picture dawn on a huge canvas (i.e. evolving our perception of realty closer and closer to true-reality). Mankind must find accurate description and nature of various kinds of parts and various kinds components (i.e. sub disciplines), which includes clearly documenting each part/piece of knowledge for easily recognizing finer differences in each of the parts like best discriminating connoisseurs.

The very purpose of scientific research is to evolve humankinds understanding (or perception) of reality closer and closer to absolute truth. It is like painting a clearer and clearer picture by using brighter colors (e.g. by research papers and results of experiments) to bring into focus blurred/invisible details of each small part/piece of very large picture drawn on a huge canvas.

If science is progressing in right/wrong direction, drawing clearer picture one small piece at a time to bring each piece into focus is what scientists do. Mankind’s experience/history proves that a flaw in seed axiom side tracks the scientific progress into a paradoxical paradigm and the field sooner or later end up in crisis, which containing many inexplicable contradictions and anomalies. In this case, if there are errors in seed axioms, the picture of mankind’s perception of reality end up moving further and further away from absolute truth/reality.


Mankind must erase old picture (i.e. perceived reality) evolved for decades by relying on flawed seed axiom and must start redrawing a new picture of reality by relying on flawless axioms. It is a complex/contentious endeavor to evolve a new reality (in right direction by relying on error free seed axioms) for replacing old perception of reality (evolved for decades in wrong direction) – a true Gestalt shift. Also referred to as Kuhnian paradigm shift. The 2 pictures in FIG-1 & FIG-4 respectively presents mankind’s 2 perceptions of realities, before and after exposing the error in seed axiom of Geocentric-paradigm prevailed until 500 years ago: http://real-software-components.com/more_docs/epicyles_facts.html.

Sunday, October 26, 2014

First Principles of CBD of physical products: Falsifiable Facts for the CBD (Component Based Design)


What do we know about the CBD (Component Based Design) of physical products? What are the irrefutable facts (e.g. essential aspects) of the CBD of physical products? Answer: Each physical product comprises hierarchies of replaceable components. Over 90% of features and functionality is implemented as components. Total cost (or complexity) of disassembling (or reassembling) of any physical product is between 1% to 20% of the cost (or complexity) of designing and building all of the components used for building the product.

What is the true essence of the CBD of physical products and the physical components? It is not reuse, not standardization, nor any such other stuff (e.g. erroneously attributed to so called software components). The Irrefutable Answer is: No spaghetti code. What are the striking characteristics of elephant? Simple answer is, its big size, trunk and tusks. What are the striking characteristics of CBD of physical products? Simple answer is: containing one or more “hierarchies of replaceable components” and “no spaghetti code” (either within each of the components or within the ‘component hierarchy’).

The physical product and each of the components contain no spaghetti code. There is no spaghetti code within each component in the hierarchy. If I am responsible for a component ‘component-X’ (e.g. to refine the component little-by-little), I can unplug component-X to redesign it (e.g. blueprint or source code) individually (to make it as best as it can be) and test it individually and plug-in. This is true for each of the components in the component hierarchy. The design of each component (i.e. blueprint or code) is refactored individually to make it spaghetti code free. There is no spaghetti code at the level of the product. The spaghetti code is eliminated or minimized at the product level, since over 90% of the features and functionality (i.e. source code) of the product is implemented as such components (where each component is free from spaghetti code).

It is not necessary that, even a single component in the hierarchy possess any of the properties (e.g. reuse, standardized) erroneously attributed to so called software components or conform to any so called software component models exist today. The single most important aspect and true hidden essence of real components for true CBD is: “No Spaghetti Code”. Implementing even a portion of the functionality or features of a software application as components proportionally reduces the spaghetti code. Today no conscious effort is made to identify SCCs to build even small portion of each of the applications by using replaceable components (or RCC) to proportionally reduce spaghetti code.

Today no large software product is created as hierarchy of components. But it is possible to build many GUI applications as hierarchy of replaceable components. For example, this City-GIS application is created as hierarchy of components. In fact, today it is impossible to find code base for even a single large SCC (‘Self-Contained Component’) of size City_ATC that is implemented as a RCC (Replaceable Component Class) to make it free from spaghetti code.

It is possible to identify many SCCs in any exiting non-GUI-application, where each SCC can be implemented as a replaceable components (to make it spaghetti code free) but are not implemented as replaceable components (so started its life as spaghetti code and its developer is forced to refine this spaghetti code many times even before first release). Alternatively, it is easy to prove that, a large portion of functionality and features of most of the non-GUI-applications are implemented as SCCs, where each of the SCCs can be designed as a replaceable component but today no conscious effort is made to identify each SCCs to design the SCC as a replaceable component.

Today it is impossible to find even a single theory or hypothesis, (that is based on hunch, guess or wishful thinking), accepted as a fact (without testing it against whole world of known/recorded observations to falsify the theory or hypothesis), for example, to advance any scientific or engineering field for decades by blindly relying on such untested fact. One of the previous well known examples is geocentric paradigm, and exposing the error in the seed axiom resulted in greatest scientific revolution known to mankind.

It is not hard to prove that there exists a truth and the truth can be discovered, where the truth is ‘there exists a set of essential properties that are uniquely and universally shared by each & every physical functional component known to mankind’ and the set of essential properties (i.e. truth) can be discovered. This discovery is akin to discovering that the Sun is at the center, which exposed flaw in then widely accepted fact ‘the Earth is static at the center’. Likewise, it exposes errors in seed axioms of CBSD by proving that no other kind of software part can be a component without sharing the essential properties.

Once the set of essential properties (or characteristics) of physical functional components is discovered, it is kind of trivial task to identify SCCs in case of GUI applications. But today no attempt is made to identify even the simpler SCCs in the GUI applications. Although it is not hard capability to implement, no other GUI library (e.g. Java/Swing, Windows/VB) is implemented to encapsulate each of the larger SCCs in a class definition (to make it free from spaghetti code by implementing the SCC as replaceable component class).

In case of non-GUI-applications, any SCC can be implemented as replaceable component class, but it is not a simple task to identify SCCs in each of the non-GUI-applications (even after discovering the set of essential characteristics of physical functional components). To identify SCCs in non-GUI-applications, one requires in-depth knowledge about the innate nature and essential characteristics of physical functional components backed by more experience (e.g. in identifying SCCs in GUI applications) and/or hands on training form a person who is expert in identifying SCCs.

Current state in summary: It is easy to identify SCCs in GUI-applications, but no conscious attempt is made to identify them. Even if large SCCs are identified, it is not possible to make each of the SCCs free from spaghetti code (by designing each of the SCCs as a RCC) due to the limitations of the exiting GUI libraries such as Java/Swing or Windows/VB. On the other hand, it is not a trivial task to identify each of the SCCs in non-GUI-applications, but any such SCC can be implanted as RCC (but no conscious effort is made to identify SCCs, so almost no SCC is implemented as a RCC to free it from spaghetti code).

One must implant this picture (i.e. FIG-2 of CBD-structure) in his mind and one must never forget this structure and the essence represented in the image. The essence represented by logical CBD-structure is referred to as: Hierarchy of replaceable components. Hierarchy of replaceable components is the logical structure of any CBD of physical product. The objective of my research spanning nearly a decade is to achieve equivalent structure (hierarchy of replaceable components) for any complex software applications. The equivalent structure for software applications is represented by the picture (i.e. FIG-1 of City_GIS), where no RCC requires more than 3 to 5 lines of code to assemble (and disassemble) each of the respective RSCCs. These 2 pictures are burned into my memory (or hard wired into my mind).

My single minded objective and obsession is to achieve the hierarchy of replaceable components for software applications. The way I accomplished this objective is by discovering the innate nature and the set of essential properties of physical functional components, since no other kind of physical part except a very special kind of physical part (known to mankind as components) having very unique properties can achieve such structure. The physical functional components are very special kind of parts having very unique nature and essential characteristics, which are unknown to the mankind, hence must be discovered to positively identify equivalent parts in software applications (e.g. to implement each equivalent part as a replaceable component).

If an application has 100 such SCCs (Self-Contained Components), our CBSD requires implementing each SCC as a replaceable component. Then it requires no more that 300 to 500 lines to assemble 100 replaceable components. That is, it needs 3 to 5 lines to assemble each replaceable component and removing the 3 to 5 lines must effective remove the replaceable component without leaving any traces. The collaboration between the components is handled using intelligent CASE-tools such as this CASE-Tool. There is no need for implementing any more communication code for each of the replaceable components, so there is no need for removing any communication code (when removed the component or replaced by an equivalent replaceable component).

Another falsifiable fact (but it is impossible to find a flaw) is, neither complexity nor uniqueness of one of a kind physical product (e.g. prototype of a spacecraft or experimental jet-fighter) can prevent its designers from achieving hierarchy of replaceable components. In contrast, today even 10% of the functionality and features is implemented as replaceable components in each of the large applications. Let me define a term: achieving X% modularity for a software application implies, implementing X% of the functionality and features of the application as replaceable components (or RSCC).

Even for argument sake, if it is not possible to achieve 90% modularity, there is no valid reason why it is not possible to achieve 30% to 50% modularity. Whatever excuse or justification one can find, I am sure, I can find a flaw in the justification. Any excuse to rationalize exist paradigm is falsifiable and it is not hard to find flaws in each of the excuses (or justifications). For example, if one insists that there exists no such set of essential properties for physical functional components, I can prove that there exits a truth (i.e. a set of essential properties) and the truth can be discovered. For example, if one says it is impossible to invent equivalent software components, I can identify few SCCs in any existing application that can be implemented as RCCs (but each is implemented as spaghetti code for no other apparent reason).

There is no valid reason why design of software products alone must be infected with spaghetti code. No other kind of physical parts can achieve the highest degree of modularization possible for the components, so it is essential to discover the unique hidden characteristics that are enabling the components to achieve such high degree of modularization. I am providing many falsifiable assertions and concepts in support of our new paradigm, and I am sure it is impossible to find a flaw for any of my falsifiable assertions and concepts. On the other hand, it is not very hard to find flaws in each of the excuses or justifications given to defend of rationalize the existing 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).

Few more interesting facts & observations about physical components & CBD:

Most of the features or functionality of a physical product is provided by the replaceable components, if the product is created by using CBD, where each replaceable component provides a subset of features and/or functionality of the product. Each component might depend on services (i.e. functionality) of one or more other replaceable components and/or provide one or more services (i.e. functionality) for the other components. The components in a CBD-product collaborate with each other by requesting services of each other.

What are the striking properties of physical functional components? Each of the components is designed to provide a subset of functionality or features of the container product (or component). Another striking difference between other kinds of parts and components is, the components are self-contained, so requires no more construction or configuration, so can be assembled readily. Likewise, each component can be easily disassembled as a unit at any time in the future, for example, either replace by an equivalent component or to refine and test it individually and reassemble. But other kinds of parts (e.g. ingredient parts) require substantial construction and configuration at manufacturing site for using as a sub-part for building container product (or component). Except components, no other kind of part can be disassembled (in the future) to test it individually outside of the container product (or component).

Saturday, October 4, 2014

Requesting software scientists and researchers to discover the light of truth for overcoming the darkness of ignorance and resultant software crisis


Known Facts about the Physical Functional Components: The physical products are built using many kinds of parts such as ingredient parts (e.g. steel, cement, metals, glass, silicon or plastic), mixtures (e.g. led and acid in led-aced batteries), alloys, tightly coupled parts (e.g. copper strings and plastic insulator in electric wires or threads in a cloth) and of course components. It is foolish to define that any kind of part having one of more useful properties (reusable or standardized) is a component.

Don’t we know that the components are a very special kind of parts having unique characteristics for achieving CBD (Component Based Design – hierarchy of replaceable components)? Except components, no other kind of parts can achieve equivalent hierarchy of replaceable parts. What is the hidden nature that is enabling them to achieve the hierarchy of replaceable parts?

            If we show to an expert a part and ask him, weather it is a component or it is not a component, I am sure he must have no problem positively identifying it. That is, if it is a component, he would say that it is a component. If it is not a component, he would say that it is not a component. He may make a mistake in case of very small non-functional parts such as bolts, screws or panels. He might fail in very rare fringe cases (e.g. false positively or false negatives). But he would not fail in case of functional components such as CPU, Engine, CD-player, car-battery or hard drive, where a functional component is a component that is built by using more than one part to perform a function of a container product.

            What are the unique striking characteristics that are allowing the experts positively identify the functional components? What are the features or characteristics unique to the functional components that are allowing the experts to positively distinguish functional components from other kinds of parts? Today software engineers are clueless about the nature of the physical functional components and CBD. The sad part is, scientists of computer science and researchers of software engineering refuse to discover the light of truth, that could expose huge error that side tracked the software engineering for nearly 50 years.

            Please kindly remember, the purpose of components is achieving hierarchy of replaceable components, which results in eliminating the spaghetti code. It is not necessary that even a single components in the hierarchy to have any properties (e.g. reusable or standardized) erroneously attributed to software components nor conform to any existing so called component models.

The computer science and software engineering research community committed a huge error. The sad part is scientists and researchers refuse to learn the truth and use the light of the truth to overcome the darkness of ignorance (e.g. to solve software crisis, which is due to the darkness of ignorance). It is beyond my grasp, why research community refuses to discover the truth (e.g. by acknowledging the obvious facts and analyze the facts and simple observations). I believe, discovering the truth (e.g. by starting with essential characteristics of functional components and CBD) shall put the computer science on the right path that leads to an unprecedented revolution in software engineering.

Research is nothing but pursuit of absolute truth and pursuit of absolute truth is sacred duty of any real scientist. Refusing to discover the truth (e.g. nature such as essential characteristics of physical functional components or essential aspects of CBD of physical products) is nothing but abdicating the sacred duty. Once the essential characteristics of physical functional components are discovered, it is impossible to find a valid reason, why is not possible to invent equivalent software components for achieving component hierarchy of replaceable software components (e.g. that eliminates spaghetti code), where the hierarchy of replaceable software components is equivalent to the hierarchy of replaceable physical components that is an essential aspect of the CBD of physical products.

For example, how can any software expert conclude that it is impossible to invent equivalent software components without even trying to know the essential characteristics uniquely and universally shared by each and every physical functional component known to mankind? The experts of various physical products have been using the tacit knowledge about the essential characteristics unconsciously either to positively identify each of the physical components or to positively differentiate each of the physical components from other kinds of physical parts. It may take few weeks of handwork to convert this kind of tacit knowledge into explicit knowledge to positively identify equivalent software components, but acquiring such explicit knowledge is not impossible.

There exists a truth and the truth can be discovered. It is not hard to discover the truth. My humble request to scientists of computer science and researchers of software engineering is kindly discover the light of truth for overcoming the darkness of ignorance and resultant software crisis. It is a fact that the computer science is in darkness, because no effort is made to discover various kinds of physical parts for categorize various kinds of parts by discovering essential characteristics (and purpose) of each kind of parts.


Saturday, May 24, 2014

There is only one possible Right Path for scientific progress and scientific progress stagnates, if an error sidetracks the progress into a wrong direction.


There is only one possible Right Direction for scientific progress. It is not possible for any meaningful progress for any scientific field if the field ended up in a wrong direction by making a mistake (e.g. a mistake sidetracks the research of any scientific discipline). Each and every scientific fact exist on right path and there exists only one right path, so no useful discovery can be found, if an error deviates researchers into wrong path.

The software engineering ended up in a ditch, because the basic facts or concepts such as definitions for so called software components and CBD for software made out of thin air (without any basis in reality). It is impossible to find any evidence that the definitions for software components and CBSD are made out of thin air, by ignoring known reality and in contradiction to reason and logic:
1.                 Each kind of software part or module either having certain characteristics (e.g. reusable or standardized etc.) or conform to a so called component model is defined as a kind of a software component.
2.                 Using one or more kinds of such so called software components is defined as a kind of CBD for software.

Please refer to the figures in WebPage: http://real-software-components.com/more_docs/epicyles_facts.html. FIG-1 shows the reality of planetary paths until 500 years ago. Thousands of concepts, observations (e.g. experimental results) and facts were accumulated for 1000 of years by concluding that ‘the Earth is at the center’. All these concepts, observations (e.g. experimental results) and facts were derived by realign that the erroneous fact ‘the Earth is at the center’ (i.e. geocentric model). Each fact or concept added by relying on observations (e.g. experimental results) and earlier concepts/facts under the influence of conformational bias. Each fact and concept was consistent with this perceived reality and re-enforced the strength of perceptions and conventional wisdom.

            About 500 years ago Copernicus questioned the validity of the root axiom ‘the Earth is at the center’ (i.e. geocentric model). He proposed that ‘the Sun is at the center’ (heliocentric-model). After many decades of struggles and sacrifice of great researchers (e.g. Kepler, Bruno and Galileo) alternative reality emerged, this is shown in FIG-4. Few break away group of researchers created hundreds of new concepts, observations and concepts by concluding that the heliocentric-model is a fact and by relied on heliocentric-model.

            During this transition period from geocentric model to heliocentric model, the researchers divided into two camps, where one camp (or school of thought) insisting that the geocentric-paradigm is reality while other camp (or school of thought) insisting that the heliocentric-paradigm is reality. Each paradigm is comprised and supported by hundreds or thousands of concepts, facts and observations (which were accumulated for many years). Each concept and fact belongs to any paradigm is consistent with other concepts and facts of the paradigm, where most of the concepts and facts are either interdependent with each other.

Of course, the researchers advance any scientific discipline by adding more and more new facts, concepts and observations (e.g. including results of experiments). Each of the new concept or fact is derived by relying on already existing concepts and facts of then prevailing paradigm. If the new concept or fact is verified and accepted, the new concept or fact would become part of knowledge base of the paradigm for other researchers to create more new concept or fact. This knowledge base can be seen as a matrix or web of interdependent concepts and facts.

I liked Mr. Ian Phillips analogy sparse matrix for the knowledge base of mankind, where each non-empty cell contains a fact or concept having varying degree of accuracy or clarity. That is, some facts or concepts are 100% accurate (or clear), while other facts or concepts are X% accurate or clear (where X% is a number between 50% and 100%). I feel, a puzzle or matrix is a good analogy for a paradigm, were no cell is empty but contains a piece (i.e. fact, concept, observation or empirical evidence). Although each of the concepts or facts of a paradigm is not 100% accurate, each fact or concept is consistent with other facts and concepts of the matrix. All the concepts, facts and empirical evidence together paint the reality of the paradigm on the puzzle or matrix (e.g. by filling each cell with a piece of the painting having various degree of clarity/accuracy).

If the error geocentric-model is not exposed, few more thousands of concepts, facts and empirical observations would be accumulated and added to the expanded matrix (by now). Each of the added concepts, facts and empirical observations compliment each other and in consistent with the perceived reality (i.e. FIG-1). But now we know that it was a wrong path and the erroneous geocentric axiom sidetracked the scientific progress into a wrong path.

Then deeply entrenched geocentric paradigm and then evolving heliocentric paradigm co-existed for few decades, where each school of thought (i.e. paradigm) tried to discredit the other school thought. The proponents of heliocentric model faced very complex questions, such as, if the Earth is moving (i.e. circling the Sun) why the moon is not left behind (i.e. how could the moon is circling the moving Earth)? It was impossible to find any valid answer, since gravity was not yet discovered. But Galileo was able to find an empirical explanation: He discovered that Jupiter has moons and the moons are circling the Jupiter. It is a valid explanation and empirical evidence, since both camps agree that the Jupiter is circling a planet that was at the center. That is, one camp believed that the Jupiter circling the Earth, while the other camp believed that the circling the Sun, but no one disputed the fact that the Jupiter and other planets such as Saturn are circling/moving. Galileo improved telescope, which allowed him to see that Jupiter has moons and the moons circling the Jupiter.

Eventually the heliocentric paradigm won because it provided far more accurate predictions for paths of planetary orbits (e.g. by removing inexplicable epicycles and retrograde motions from the planetary paths). For example, astronomers were able to predict planetary positions far more accurately by using laws of Kepler. The heliocentric model resulted in far more accurate concepts, facts and predictable observations having fewer and fewer inconsistencies by having far higher degree of clarity and accuracy (e.g. for each of the concepts or facts for each of the pieces/cells in the puzzle/matrix).

The biggest and irrefutable proof for the heliocentric-model was that it put scientific progress on the right tracks and allowed the science to progress on right tracks, since It is not possible for any meaningful progress for any scientific field if the field ended up in a wrong direction by making a mistake (e.g. a mistake sidetracks the research of any scientific discipline). This progress resulted in discovery of Newton’s laws of motion and gravity, where these laws of science provided irrefutable proof and decisive victory for the heliocentric-model.

In light of all this knowledge of history and accumulation of scientific knowledge one can show: There is only one possible right direction and researchers can make progress by finding and staying on the right path. An error such as ‘the Earth is at the center’ can sidetrack the progress and end up in a ditch. If a scientific field ends up in wrong path, and researchers apply brute force to advance the field, the resulting matrix of concepts and facts that are less accurate and reliable for making predictions. Also comprises of anomalies and inconsistencies that are justified by using silly excuses (e.g. software is different or unique, without providing any valid justification for why and what manner software is different or unique).

The designing of any complex software is not unique or different from designing of complex one-of-a-kind physical products. It is possible to discover the essential properties uniquely and universally shared by each and every known physical functional component. Likewise it is possible to discover essential aspects/concepts uniquely and universally shared by CBD of each and every physical product.

Once the essential properties and the essential aspects/concepts are discovered, it is possible to invent real software components (e.g. by having the essential properties) for achieving the real CBSD (CBD for software), where the real CBSD is shares the essential aspects/concepts and equivalent to the CBD of physical products. A new matrix of concepts and facts would evolve for real CBSD, where each of the concept or observation would be equivalent and identical to the concepts exist for the matrix of CBD of physical products and physical functional components. However, today already there exists a complex matrix of concepts, facts and empirical results for software engineering and CBSE, which resulted from untested definitions for software components (which are made out of thin air). Please refer to the exiting definitions for software components given at the top.

If there are errors in above definitions, it is a scientific miracle for software engineering to make any meaningful progress and no meaningful progress is possible until the errors are fixed for putting the progress in right direction. The discoveries such as gravity, laws or motion can be found only when science is progressing in right direction, since such scientific truths exists only on the right path.

Only way to keep the scientific or technological progress on the right path by making sure that critical concepts and facts are free from fatal errors. It is not necessary that the facts and concepts must be 100% accurate. For example, Copernicus only proposed that the Sun is at the center, and assumed that the planets are traveling around the Sun in circular orbits (while in reality the planets were traveling around the Sun in elliptical orbits). Although it is not error free, the discovery of Copernicus is a step in the right direction (while geocentric model evolved by relaying on a fatal error).

I am sure Kepler must have realized that the earth is traveling in an elliptical path around the Sun (since he is living on the Earth and by measuring the approximate distance between him and the Sun for few years to plot the path). If this resulted in elliptical path, he could hypothesis that other planets also must be also traveling on elliptical paths, which can be confirmed by tracking their locations for few years. Also Keler’s greatness was that he gained valuable insights, which were quantified by his 2nd and 3rd law. I am sure, the third law was instrumental in determining that the gravity is inversely proportional to the square of the distance (instead of just distance or cube of the distance).

I have been doing research on nature and essential aspects of real software components and CBD of physical products for more than a decade. I am confident that I found accurate definitions for real software components and real CBSD. These definitions resulted in a new paradigm supported by a matrix of concepts, facts and empirical evidence (or experimental results). For example, experimental results include building software applications as hierarchy of replaceable components by assembling software components (that are equivalent to the physical functional by sharing the essential properties).

My website contains many WebPages that present various concepts and aspects of a matrix for the newly proposed CBSD paradigm. The concepts, facts and observations are consistent with each other and with the new reality that is resulted by relying on our accurate definitions for real software components and CBSD. Even if the concepts and facts are not perfect, they are consistent with the reality (in light paradigm for physical functional components and CBD for physical products). It is error to validate these concepts by relying on the concepts in the matrix for old paradigm.

If one is going is a right path, he finds many concepts that perfectly complement and fit with each other. This assures him that he is going in the right direction. Also he can make predictions and find evidence that his predictions are accurate. I believe, this new paradigm can offer 5 to 10 folds increase in manual productivity for large software applications. The new paradigm is much simpler and answers many questions that were not answered by older paradigm.

But experts unfortunately feel new paradigm is complex, because they need to learn few dozen new simpler concepts, even if the older paradigm has hundreds of much harder concepts (since they already mastered concepts in the matrix for older paradigm over the years). For example, the researchers already absorbed and digested the concepts in the older paradigm without questioning their validity (from by reading text books and in class rooms as students). But in case of concepts of newer paradigm, they question the validity of each of the concepts in light of the erroneous concepts and facts of older paradigm. For example, 500 years ago saying that the Sun is at the center offended common sense and deeply entrenched conventional wisdom.

P.S: It reminds me of my ‘Vi’ and c-shell skills of Unix. For many years, I was much comfortable with ‘Vi’ and 2 or 3 letter aliases for doing any thing. For example, in Unix I had an alias to go to any folder, since all the projects I work has aliases, but I need to make many selections using mouse to go to a working folder. I reluctantly learned the editors and mouse, only when I was forced to develop software on PC using IDE. I worked over five years on Unix so highly accustomed to the environment, but it may take few months to get the same level of comfort (so I was reluctant to learn new paradigm, so to speak).

Saturday, February 22, 2014

A simple proof for high school graduates: Software engineering is in crisis because software researchers abdicated sacred duty and ignored basic scientific processes.


The objective of this blog is to provide a simple irrefutable proof, which can be understood even by a high school graduate: Today computer science is a science fiction and software engineering is in crisis, because the software researchers ignored basic scientific processes and continue to abdicate their sacred duty. If one searchers for phrases in Google such as “Is software engineering a real engineering” or “Is computer science a real science”, one can find many articles persuasively arguing that software engineering or computer science are flawed discipline.

Computers science can never become real science and software engineering can never become real engineering until software researchers and scientists discover answer to very basic question “What are the essential properties of ideal physical functional components”. Please kindly allow me prove that computer science is a science fiction, without knowing answers to this kind of primitive facts about basic building blocks.

The answers to the following questions are many times complex than the above question. For example, school teachers are teaching characteristics of plants to 4th graders: http://www.slideshare.net/allsaintsscience/4th-grade-ch-2-lesson-1-what-are-plants-characteristics. Without knowing answer to this question (i.e. such basic characteristics), can the botany be a real science? Discovering “what are the characteristics of the animals” must be at least 25 times more complex than discovering “what are the characteristics of the physical functional components”. Without known answer to this question (i.e. such basic characteristics), can the zoology be a real science?

Any scientific field (e.g. botany, zoology or software) end up as a science fiction, if scientists blindly define essential properties of basic entities (e.g. plants, animals or components for software products) without any basis in reality (by ignoring and in clear contradiction to facts) and try to advance the scientific field by stubbornly relying on the erroneous essential properties of basic entities (or building blocks).

Today no software researcher can name any two essential properties that are uniquely and universally shared by ideal physical functional components. If any expert disagrees, I respectfully challenge him to name such essential properties of ideal physical functional components. Does any scientific field progress without knowing answers to such basic building blocks? Since I already discovered essential characteristics of physical functional components, let me assure that, this answer is far simpler than many other known answers, even school kids consider trivial facts.

Mankind has no problem naming essential properties of millions of physical beings (e.g. elements, molecules, plans, animals or bacteria etc.). Let me provide few more examples: What are the essential properties of atom (or molecule or compound)? What are the essential properties of hydrogen (or oxygen, gold or water)? Answers to such questions are well known and today considered trivial facts. Any scientific field ends up in crisis (or in a paradox), if there are errors in such basic facts.

What is the essential property of Hydrogen? Ans: An atom can be Hydrogen atom if and only if it has just one proton at its nucleolus. What is the essential property of Gold? Ans: An atom can be Gold atom if and only if it has 79 protons at its nucleolus. What is the essential property of Oxygen? Ans: An atom can be Oxygen atom if and only if it has 8 protons at its nucleolus. What is the essential property of Water? Ans: It is made of molecules, where each molecule contains one oxygen atom and 2 hydrogen atoms. What is the essential property of Silicon? Ans: An atom can be Silicon atom if and only if it has 14 protons at its nucleolus. Along with such countless interrelated basic facts, even smart school kids has huge amount of accumulated tacit knowledge.

Any scientific field ends up in dark ages without knowing such basic facts or relying on such unsubstantiated erroneous facts. It is impossible for scientific progress in each of the scientific fields without knowing accurate answers to thousands of such basic facts and accumulated tacit knowledge. Of course, even high school graduates don’t ask, what is a proton or atom, because they already have tacit knowledge about them.

Every mature paradigm results in huge accumulation of such tacit knowledge and deeply entrenched collective conventional wisdom. Unfortunately software engineering has been evolving for few decades (by relying on myths) and now it is a mature paradoxical paradigm having accumulated tacit knowledge and deeply entrenched collective conventional wisdom. In such a mature paradox, the researchers not only learn to accept contradictions but also foolishly justify the contradictions by using silly excuses such as our field is different or unique. Even simple contradictions otherwise obvious errors perceived as trivial facts.

The software researchers erroneously defined many kinds of software components, where each kind of software components is a kind of software parts having certain properties (e.g. reusable or standardized) or conform to a so called component model. These insidious axioms have no basis in reality of facts. The software researchers have been doing research on software components and CBD for more than three to four decades by relying on such baseless myths (i.e. assumed to be proven facts). But the shocking fact is, it is impossible to find any other software researcher ever tried to discover accurate answer to this basic question: “What are the essential properties of ideal physical functional components”.

My objective is to respectfully inform that it is a huge error to not discover the accurate answers for such basic building blocks or facts of computer science and software engineering. Many experts insist it is impossible to discover essential properties of physical functional components for achieving real-CBSD. I vehemently disagree, since we already discovered them. If they are true, they must not have a problem finding a flaw, when some one claims to have discovered essential properties of physical functional components for achieving real-CBSD.

Many other experts erroneously insist that it is impossible to invent software components that are equivalent to the physical functional components (e.g. by having essential properties uniquely and universally shared by each and every physical functional component) for achieving real-CBD for software products, which is logically equivalent to the CBD of physical products and offer comparable or better benefits. I vehemently disagree, since we already secured US-patents for such real-software-components. I can demonstrate countless components and component hierarchies, only if they are not determined to be willfully ignorant.

I have been trying to make many experts aware of possible errors in the basic aspect of software engineering, but unfortunately I hear countless excuses and evasive responses. To answer their questions in good faith, I created so many responses and comprehensive proof for each aspect. It made my website become so big and comprehensive. I created many repetitions of same information for providing irrefutable proof in multiple perspectives due to my eagerness to respond to every excuse by not realizing that some of their snubs are mere evasive tactics.

You can lead a horse to water, but you can't make him drink. What can any one do, if scientists of botany or zoology use evasive excuses such as it is impossible to discover essential properties of plants or animals respectively? This blog provides irrefutable proof that that existing software engineering paradigm evolved by relying on a huge error. I am sure, even a high school graduate should not have problem understanding this simple proof (i.e. that it is a huge error, if even the best software researchers can’t name essential properties that are uniquely and universally shared by each and physical functional-component).

I have been trying to make the software researchers aware of this huge error, but they are pretending to be busy or not seen/heard my emails/calls. You can't wake a person who is pretending to be asleep. Many experts give long lectures about research but do nothing else, which is nothing more than self-promotion and hypocrisy. Any scientist or researcher must be ashamed of himself for not having intellectual curiosity. It is an intellectual dishonesty (or incompetency), if any scientist or researcher refuses to defend facts he is advocating (especially when clear evidence is provided to expose errors in such facts).

Our website contains irrefutable facts and comprehensive proof (e.g. evidence and reasoning) for each and every aspect. I am respectfully offering light of truth that can lead the software engineering way out from software crisis. It is up to each to accept or reject my humble offer. If any one wish to know any clarifications or more evidence (e.g. facts or reasoning), I am not only happy but also eager to provide necessary help in exposing this basic error.

Existing paradoxical paradigm and accumulated tacit knowledge is result of passionate research spanning many decades by erroneously concluding essential properties of components are reusability or standardized etc. Of course, is it any wonder why such error sidetracked technological progress of software engineering? It is impossible to put the scientific and technological progress on right tracks without exposing such basic errors.


Monday, February 10, 2014

Scientific research for disruptive discoveries need ruthless pursuit of Truth/Facts, even if it appears or perceived to be arrogant or disrespectful.


The sacred shared duty of each and every researcher or scientist is pursuit of absolute truth (or facts). Any researcher or scientist must be ashamed of assuming or believing oneself a researcher or scientist, if one either doesn’t know the shared sacred duty or ignore/evade the shared sacred duty (e.g. denying facts by using silly baseless excuses). The scientific and technological progress is nothing but expanding boundaries of human knowledge by discovering objective facts (or truths).

Please allow me to provide few examples: Scientific research in chemistry is discovering, studying, organizing the knowledge and cataloging properties of elements, compounds or chemicals. The botany is discovering, studying, organizing the knowledge and cataloging properties of plants. The zoology is discovering, studying, organizing the knowledge and cataloging properties of animals. The scientific progress in each of the above scientific fields is nothing but discovering new facts for expanding human knowledge.

Unfortunately most software researchers argue, it is impossible to find essential properties of physical components. If this is true, the entire scientific progress we made in each of the basic fields is wrong and nothing mankind invented and built by relying on the scientific discoveries could work. Why can’t any one make same argument for each of the basic sciences (e.g. chemistry, botany or zoology)? How could any of the basic sciences (e.g. chemistry, botany or zoology) exists, if this argument is true?

The purpose of scientific research is discovering relevant facts for expanding the human knowledge. The basic effort and purpose of engineering research is to invent useful things by rely on a “set of core or necessary facts” discovered in the scientific research. None of the useful invention we are using everyday and take it for granted could ever work, if there are errors in the “set of core or necessary facts”.

About 45 years ago software researchers blindly defined properties of components without any basis in reality or facts. Over time those unsubstantiated assumptions became axioms (assumed to be de facto Truths). No one ever either questioned their validity or even suspected possible errors in the unsubstantiated axiomatic assumptions. In spite of effort spanning four decades by millions of researchers, engineers and experts no breakthrough invention or even meaningful progress is made in CBSD, because they have been relying on myths (i.e. unsubstantiated axioms assuming to be de facto Truths). Isn’t failure expected outcome of any research, if there are errors in “essential set of facts”?

What are the “core or essential set of facts” for inventing real software components and CBD for software? Is it impossible to discover essential properties uniquely and universally shared by each every physical functional component? If it were true, I respectfully challenge to find a flaw in the essential properties discover and proposed (in our website)? Why any expert should have any problem finding a flaw in the essential properties proposed (in our website), if it is impossible to discover the essential properties?

Is it wrong if I demand any researcher or scientist to finding a flaw in my discoveries (e.g. essential properties of components and essential aspects of CBSD) proposed in our website, if he uses either baseless excuses (e.g. software is different or unique) or argue that it is impossible to discover essential properties of physical components?

As a scientist, one must ruthlessly peruse facts and truth. For example, he has no need to explain financial implications. He should not be overly concern with egos of respected scientists (as long as he meant no disrespect and his objective is only to firmly and respectfully state facts). It sounds or perceived to be arrogant and disrespectful, when any one say I am right and every one else is wrong. But when it is the case, how any one can politely or humbly but firmly request for an opportunity form respected researchers to demonstrate proof.

I am sure it would hurt egos of some researchers, but competent researchers know that it is justified (if they can’t find any flaw in the proposed inventions and discoveries). I am sure any good scientist or researcher would appreciate such humble effort to force him/her to see the facts, reason and light of truth (especially when the facts end up saving his and others from wasting their passionate effort for advancing technology by relying on erroneous facts). I have utmost respect for respected researchers and I meant no disrespect. Unfortunately stating certain kinds of facts appears or perceived to be arrogant and disrespectful, and I humbly state that I meant no disrespect.

Unfortunately few irrational skeptics try to sidetrack the debate by demanding financial implications or usefulness of the discoveries. The truth is the God in the religion of science and ruthlessly perusing the Truth is the best way to practice religion of science. No one could have named tangible financial benefits, if one demands 500 years ago what difference it would make by proving the fact (e.g. the Sun is at the center)? But now we answer that question: The mankind would still be in Dark Age, if that fact is not yet discovered. How could Newton discover and propose Gravity without Kepler’s laws?

For example, now there is a debate raging about the very existence (or “nature of black holes”) after Stephen Hawking changed his mind and proposed a new theory to solve a paradox surrounding the fundamental building blocks of how the universe works. Mankind can never see a black hole and countless aspects are unknown and can’t be predicted with any certainty. All the theories are at best educated guesses based on very little information or at worst pure speculation. Why should we care about the “nature of black holes”? What tangible benefits it can have on world economy.

This is true for any basic research. What difference it makes, if dinosaurs were extinct due to collision of meteor or wiped out by a killer virus? Why governments investing billions on basic scientific research and building expensive research equipment and facilities (e.g. CERN’s Super Collider). It is impossible to provide a concrete answer, except saying, without ruthless pursuit of truth/facts mankind would still be in the dark ages. And history taught us valuable lesions that, ruthless pursuit of truth/facts is the only way for advancing science and technology. Even if truth has no apparent value at that time, erroneous facts certainly have huge costs, if researchers try to advance technology by relying on erroneous facts. For example, the software researchers wasted three decades by relying on erroneous axioms (by assuming to be facts). Exposing errors in such deeply entrenched erroneous axioms resulted in scientific revolution far greater than most of the great discoveries (Ref: Famous Book “The Structure of the Scientific Revolutions” by Dr. Kuhn).

Is the essential properties of functional physical components and CBD of physical products are as mysterious as black holes? Why software researchers even today relying on at best educated guesses (by ignoring all the known facts and observations) or at worst pure speculation made 45 years ago? If one asks 10 CBSE experts to accurately describe (e.g. to name just one essential property universally shared by) the physical components, we get 10 different accurate descriptions. Even black holes have fewer theories, and scientists readily admit that the theories are not facts, but just popular paths selected for finding the Truth. Unfortunately the CBSE experts believe their definitions are facts, so they see no need for validation or accept dissent.  Only the God has more mysterious definitions than the components, as if no one alive ever seen a physical component or CBD.

The software researchers have been relying on unsubstantiated axiomatic assumptions for inventing components/CBD, by concluding the axiomatic assumptions are facts (yet no one ever even tried to provide any evidence to show they are facts). On the other hand, there is overwhelming evidence that the axiomatic assumptions are erroneous in light of known facts and observations about physical-components and CBD. I meant no disrespect, whenever I firmly state fact (for which, if I can provide an irrefutable proof, if given opportunity).

Can any one defend their baseless silly excuse (i.e. it is impossible to discover essential properties of physical components) by naming even a single physical being mankind failed to discover accurate description (i.e. essential properties), after trying harder at least for few months and knowing as much as mankind knows about physical components. Of course, mankind has been trying to discover internal structure of elementary particles (e.g. neutrons, protons or electrons) by using string-theory or structure of unversed by using big-bang-theory for years and not yet successful, because we have very little information and know almost nothing about them. No one else is foolish enough to waste effort by relying on such unproven theories (by assuming that they are facts) for making useful inventions.

Mankind never failed to find accurate description (e.g. essential properties) for any physical being that can be seen, touched and abundantly found as the components.  Mankind discovered properties of countless things (e.g. electrons, hydrogen, bacteria or genes) we can’t even see or touch.  For example, the basic sciences such as physics, chemistry, botany and zoology discovered millions of facts (e.g. including accurate descriptions and essential properties) and made millions of successful inventions by relying on the facts. Since all these inventions are working, it proves that the facts are sufficiently accurate (within acceptable engineering tolerance). Unfortunately software researchers stubbornly using silly excuses and refusing to even try discovering essential properties of the physical components. With all due respect, I humbly state that this is not acceptable behavior for any scientist or researcher, if he assumes that he is a scientist or researcher and believes that he is doing real research.


Saturday, January 25, 2014

What is the essence of CBD (Component Based Design)? Simple Answer: Elimination of Spaghetti Code!


It is a huge error to assume CBSD (Component-Based Design for Software) is using so called software components. A simple method for discovering the real essence of CBD of physical products is to compare the differences of (a) how each of the large physical functional-components for prototype of a one-of-a-kind products (or a product newly being invented) is custom designed and build for the target physical product; with (b) how each of the large self-contained components (or software modules logically equivalent to the physical functional-components) is custom designed and build for it’s target software product.

Step-1: If I am responsible for a component Cx for a target product, I can design, build and test the component Cx independently outside of the product. Then when I feel it is ready, I can plug-in (or assemble) the component in the target product to make sure it functions as expected.

Step-2: If doesn’t fit or function as expected, I can unplug (or disassemble) the component Cx to refine little-by-little until it fits properly and functions as expected in the container physical product (or in the container-component, if Cx is a subcomponent of a container-component).

The Cx is custom designed to satisfy current unique needs of the target product. The step-1 and step-2 can be repeated for each Cx in the component hierarchy (e.g. CBD-structure) of any CBD-product.

Once, the product model is released to the market, the maker of the product need to design, build and release new models or versions of the product. I can continue to refine the blueprint (e.g. design) of component Cx little-by-little (in step-1 and also in step-2) independently throughout the evolutionary life of the target product (i.e. for each creation of successive new models and versions). Again the Cx is custom designed to satisfy current unique needs of each of the new product model.

If I am a designer of City_ATC for a target City_GIS application, why do I need to touch or even see even a single line of internal code any other components (e.g. City_LandMarks, City_Hotels or City_Map)? If I am a designer of City_Theaters for a target City_GIS application, why do I need to touch or even see even a single line of internal code any other components (e.g. City_ATC or City_Hotels)?

Please remember, if I were designer of HardDrive for a computer product, I don’t need to touch or even see tape-out Verilog code of CPU, DRAM or any other IC-Chip. Likewise, if I were designer of auto-engine, I don’t need to touch or even see a single line of code (i.e. internal design) of CD-player, gearbox or auto-battery. If I were designer of motor that spins the magnetic disks in HardDrive, I don’t need to touch or even see even a single line of code (i.e. internal design) of magnetic disks or any other component in the container component HardDrive or in the target computer product.

Therefore, in case of CBD for physical products, there is no spaghetti code. The designer of each component-Ci (for each component-Ci, where component-Ci can be any component between component-C1 to component -Cn), don’t need to touch or even see single line of code (i.e. internal deign) of any other component in the hierarchy of replaceable components (or CBD-structure).

Toady it is impossible to avoid spaghetti code in software products, since the source code of each Cx (e.g. City_ATC or City_LandMarks) is forced to spread across multiple non-exclusive files, where each of the file contain source code for more than one component. For example, today no other GUI-API is capable of encapsulating complex GUI-components such as City_LandMarks or City_ATC in a replaceable component classes (RCC), so that the component can be plugged-in by implementing just 3 to 5 lines of code and can be unplugged by deleting the 3 to 5 lines of code. It would take just few minutes to find the code base of any component, if encapsulated in a RCC (otherwise would take forever to find all code-sections spread across multiple non-exclusive files).

If I am a designer of City_ATC component (encapsulated in a RCC), I don’t need to see a single line of code of any other component, even if I work on the City_GIS application for seven years creating a new version of City_ATC component every six months for each new release or upgrade. This is not that much different from, I don’t need to see a single line of code of any other component, if I were a designer of motor that spins the magnetic-disks in the HardDrive and I need to constantly improve the motor for each of the new models for ten years.

Why the software developers today are forced to design and develop components such as City_ATC, City_LandMarks or City_TouristSpots as spaghetti code? More and more spaghetti code would be accumulated as each of the components is redesigned for satisfying unique needs of each of the newer models of the target product. Why a designer and developers of any component (e.g. City_TouristSpots or City_Hotels) need to see even single line of code of any other component in City_GIS application? The real-CBD not only eliminates spaghetti code but also eliminated reasons for accumulation of spaghetti code during the evolutionary life of products.

Many physical products (e.g. automobiles, Airplanes or super-computers) have been evolving for many decades and many successive new models have been designed with nearly zero accumulation of spaghetti code. I hope this example (using analogy of physical components) illustrate the essence of the CBD (Component Based Design). We invented all the missing pieces (e.g. GUI-API and intelligent-CASE-tools, etc) for creating real-software-components and assembling the real-software-components for achieving CBD-structure (i.e. hierarchy of replaceable components).

Let me summarize the essence of CBD is simple terms: If City_GIS application is built by assembling 6 components and 6 RCCs for 6 components are designed and built by 6 engineers (i.e. each engineer created a RCC), it is not necessary for any engineer to see a single line of code implemented in any other RCC. Likewise, if a product is built by assembling 1000 components and each of the 1000 components is designed and built by an engineer, it is not necessary for any engineer to see internal design (e.g. a single line of code or blueprint) of any other component. Any component should be disassembled or reassembled in minutes (e.g. either to replace or to redesign for successive models).

It is impossible to find a valid reason why it is not possible to achieve real-CBSD (i.e. hierarchy of replaceable components for complex software products), once essential aspects of CBD for physical products and essential properties of physical functional-component are discovered (where the essential aspects of CBD for physical products are the aspects uniquely and universally shared by the design of each and every complex product built by assembling physical components; and essential properties of physical functional-component are properties shared by each and every physical functional-component).

Analyzing the differences between ‘a’ and ‘b’ of the first paragraph at the top not only expose the huge insane error but also help discover the true essence of real-CBD (e.g. especially in the light of 3-CBD-facts).