Why software scientists refusing to investigate simple and obvious facts (that are found everywhere all around us) to discover reality?

Reality is immutable and never changes. Duty of scientists is pursuit of absolute Truths for discovering the reality (a set of Truths and laws of nature that are proven). Mankind’s perception of reality changed many times. For example, several thousand years ago mankind believed that the Earth is flat. Later 2000 years ago mankind believed that the Earth is static. Until 500 years ago this flawed axiom (i.e. “The Earth is static” considered self-evident truth) shaped our perception of reality (a paradoxical paradigm), which was altered reality filled with retrograde motions and epicycles.

            Philosophers had no problem accepting untested axiom (a Lie: the Earth is static) as self-evident Truth (even though they have no evidence any one ever validated it). But it had taken over 100 years to accept the Truth “the Sun is at the centre”. This Truth faced huge resistance and undergone most rigorous validation.

            Let me introduce reality of CBD (Component Based Development) using a small example. Mankind each year inventing and building 100s of new kind of products around the world. For example, one example is trying to create artificial kidney in this video: http://real-software-components.com/CBD/CBD_of_new_product.html.

Please kindly pay attention to 15 seconds bit starting at 1 minute 55 seconds. Let me paraphrase the 15 seconds bit, as I understood it: Essential purpose of the real component-based design is ability to look, feel & test each component independently to optimize individually for making each component as best as it can be. Periodically bring the components together to build product for making sure that (a) each of them properly collaborating with other parts, and (b) all the components are fulfilling their respective roles as intended for proper operation of the container product.

Please notice the reality of CBD: There is no spaghetti code. Each component can be refined individually and tested outside. Over 90% of the features and functionality is implemented in such components. Any component can be refined and tested individually free from spaghetti code. That is, without any need to see internal design or single line of code of any other component. Hence over 90% of the design is free from spaghetti code. Each component is custom designed to fit perfectly in just one product model, so no component is reusable, standardized or conform to any of the so called component models erroneously attributed to the software components.

Any true scientific fact, concept or discovery must satisfy two conditions (1) it must not contradict the reality we all know in the real world and (2) it can’t be falsified, while being highly falsifiable. In light of these observations, let me define the reality of ideal CBD (Component Based Design) for large physical products: The reality of an ideal CBD for physical products is implementing over 90% of the functionality and features in replaceable components, where each component can be refined and tested individually (free from spaghetti code). The physical product is evolved (or redesigned) by evolving (or redesigning) a set of replaceable components.

Nether complexity nor uniqueness (e.g. of a one of a kind product such as an experimental spacecraft or prototype of a next generation jet-fighter) can prevent designers from achieving 90% modularity. That is, the reality of CBS is implementing 90% features and functionality in replaceable components, where each component is free from spaghetti code (i.e. designer of any component never forced to see even a single line of code implemented inside another component). It is not necessary that even a single component in the product is replaceable, standardized or conform to any so called component models (erroneously attributed for software components).

Unfortunately the perception of reality for software components and CBD for software has been shaped by fundamentally flawed definitions and interpretation of the reality: When Douglas McIlroy proposed building products by assembling COTS (Commercially off the Shelf) parts as we build computers, it was just a proposal – a desire or wishful thinking. It is not a scientific discovery (like the Sun at the centre). There is no evidence any one ever tested its validity. But researchers in late 1960s considered that it is a self-evident truth, and today software researchers have been relying on this as if it is proven fact. Dr. Brad Cox proposed software-ICs in 1980s.

Because of this altered perception researchers completely lost their ability to even see obvious facts and apply reason to discover the reality. It is nice to have software-ICs, but is software-ICs possible or reality? Inventing cold fusion is nice, but can we discover laws of nature that can make it reality? I don’t know about the cold fusion, but I am sure that software-ICs as intended can never be a reality.

I requested many researchers to investigate the reality. Is Software-ICs reality? Is it possible to achieve Software-ICs for any other kind of physical product (e.g. automobiles or Airplanes), where it is not possible to use software and applications for competitive differentiation from competing products? The physical products such as cars must use core components (e.g. engine, gear-box or powertrain) for competitive differentiation from competing products.

For example, the makers or cars, jet-fighters or other products custom design core components for competitive differentiation. For example, even when they are relying on third party component vendor for a component, they work closely with the component vendor to custom design the part to perfectly fit juts one product model. For example, Boeing works closely with Rolls Royce or Pratt and Whitney to build custom engine. Likewise, Honda company works closely with makers of various non-core components such as break-pads to custom build the break-pads (to perfectly fit just one model). One can notice this kind of reality of CBD everywhere all around us.

Software researchers argue that software is unique, different and must undergo constantan changes. Why is it any different from the above example for Artificial Kidney? They must also constantly change each of the components until the whole product works. Only difference is, they don’t have spaghetti code. That is, designer of any component can refine and test his component individually, without being forced to see even a single line of code implemented internally for any other component.

Another reality is: The automobile engineers just deal with many product models within just one product family (automobile product family). Likewise, hardware engineers deals with many kinds of product models within just on product family (i.e. families such as computer or smart-phone). In software, we deal with hundreds of product families ranging from compilers, OS, Video games to MS-Office. It is impossible to reuse core components (e.g. engine or gear-box) for automobile product family can’t be reused in any other product from another product family (e.g. PC or AC). Likewise, core components for compiler product family can’t be used in any other product from another product family such as Video games.

This kind of reality about the CBD of physical products is everywhere all around us. All I am asking is to investigate such simple and obvious facts to discover the reality. Isn’t is obvious that it is impossible to achieve Software-ICs, where it is not possible to use OS and applications for competitive differentiation? Can we invent COTS that allow us to build new products (e.g. Artificial Kidney) that is not yet invented? Is such COTS (e.g. Software-ICs) for not yet invented physical products or that can be readily reusable across hundreds of families of physical products?

Often, designing each new software product is more like inventing a new physical product such as designing one of a kind spacecraft. It is desirable to eliminate the spaghetti code, because the features and functionality must be constantly changed until each of the components and the whole product satisfies the unique and exact requirements. Furthermore, this product must be changed many time in the future to make each successive release. Over 90% of the cost, time and complexity can be eliminated for making large changes by eliminating the spaghetti code.

What is the reason for spaghetti code, even one need to satisfy unique and exact needs by iteratively changing each of the parts little-by-little (e.g. see Artificial Kidney)? Nothing in the reality of CBD for physical products can prevent software designers from implementing 90% of the features and functionality is replaceable components for achieving real CBD for software. Unfortunately every software expert insists that it is impossible to achieve real CBD, without knowing what it is.

How can anyone insist something is impossible, without knowing absolutely nothing and clueless about it? It is impossible to find evidence that any one even ever tried to investigate, what is the true essence of CBD for physical products, such as what is the most useful and striking aspect that is uniquely and universally shared by every known design of large CBD product in the world.

In other words, what are the striking aspects that are unique to the CBD of physical products and universally shared not only by the designers of product models of mature product families (e.g. automobiles) and countless models of crowded product families (e.g. smart-phones), but also the designers of one-of-a-kind product models such as an experimental spacecraft, prototype of next generation jet-fighter or a new kind of fuel-cell or nuclear powered locomotive. It is impossible to find any evidence that any one ever even tried to investigate for answers to this question. But every one insists it is impossible to achieve real CBD for software, without even knowing what it is. Also most of them bluntly refusing to even know what it is.

I am sure, it is possible to achieve the goal of implementing 90% of the features and functionality in replaceable components for any software application. I am openly offering first GUI library that allow anyone to create real software components for achieving real CBD for software. The experience and insights gained while building GUI applications by assembling real software components help software designers discover the truth by experiencing reality. Also I believe, this reality will be more useful than software-ICs, especially for building large software applications.

How do we know and mankind proved, the axiom “the Earth is static” is wrong and the axiom “the Sun is at centre” is correct? Because the second axiom helped us to make subsequent discoveries that include Universal gravity and Newton’s three laws of motion. The three laws of Kepler and Universal gravity with the help of Calculus allowed mankind to create a consistent mathematical model.

These and many other unexpected discoveries (e.g. discovery of the Pluto due to inexplicable perturbations in the orbit of Uranus) conclusively proved that our understanding of reality is progressing on the right path. Of course, many other discoveries such as Theory of relativity shaping our understanding of reality, which hopefully taking our understanding closer and closer to the absolute Truth.

In software, we need to discover reality to define the realistic goals. Achieving Software-ICs is not realistic. On the other hand, it is impossible to find a valid reason why it is not possible to achieve 90% modularity. Today not even 10% of the features and functionality of any large software application is modularized as the way real physical functional components modularize the design of that large physical products.

P.S: Sample description for CBD application at: http://real-software-components.com/CBD/City_GIS.html. An example CBD application for 5 cities can be found here at: http://www.pioneer-soft.com/#/realairtraffic. Please notice Airplanes and Ambulances moving and clicking on Airplane gives real-time data. The shapes and colours indicate various states. Few other such features are not shown.

Best Regards,

Raju Chiluvuri