It reminds me Will Smith’s dialogue in iRobot (smartest dumb person), when an expert refuses to verify simple fact that contradicts his paradoxical paradigm, where the fact is otherwise simple and obvious to even a layman.

How can any one say some thing is impossible without ever even trying or even knowing what it is? No software researcher knows the answer to a simple question (i.e. what is CBD) and yet blindly insists that it is impossible, without ever even trying to know what it is (that he is insisting is impossible). How could any one conclude that it is impossible without ever even trying?

The question is: What is meant by the CBD (Component Based Design) for the large physical products? That is, what is the true essence of the CBD? For example, what are the striking aspects or characteristics uniquely and universally shared by each and every known CBD (Component Based Design) of large physical products?

In other words, what are the striking aspects 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. cell-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.

In software, we deal with 100s of product families ranging from compilers, OSs, Word, Spreadsheets, Games, Browsers, RDBMS, Hadoop, search engines, PDF and ERP etc. The design of most software products is more like designing of one of a kind product such as an prototype of an experimental jet-fighter rather than the design of a model in a crowded product family such as cell-phone, where software (e.g. OS and apps) are used for competitive differentiation but not the core components (e.g. DRAM, Screens or Flash memory).

Even in mature and crowded product families such as automobiles, the core components (e.g. engine or gear-box) are custom designed for each model for competitive differentiation. A mature product family means, first model of the product invented decades ago, while crowded product family means, hundreds of new models belong to the product family is under design by dozens of product makers each year.

Let me define “what is real CBD” (e.g. true essence and striking aspects): Implementing about 90% of the features and functionality in replaceable components (i.e. real functional components), where each component can be disassembled to redesign it individually and test it outside of the product. Once the component is made as best as it can be, it can be re-assembled to make sure it fits perfectly and performs as expected.

Every year mankind is trying to invent and design 100s of new kinds of physical products. Kindly allow me to give a simple example for real CBD. Please watch this short 3 minute video either at: http://www.real-software-components.com/CBD/CBD_of_new_product.html or at you tube https://www.youtube.com/watch?v=hc5e5cYdshI – This shows the reality of CBD of physical products, where no core component is reusable or standardized.

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 engineering is ability to look, feel and 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 fit perfectly and properly collaborating with other parts, and (b) all the components are fulfilling their respective roles as intended for proper operation of the container product.

Designer of no physical functional component needs to deal with spaghetti code/design, because it can be disassembled for redesigning to make it “as best as it can be” (e.g. refining little-by-little by finding and fixing its shortcomings) and testing it individually. Designer of no physical component needs to deal with spaghetti code, because he is never forced to see even a single line of code implemented within any other part. Each and every large physical product is free from spaghetti code, because 95% of the features & functionality is implemented in such replaceable components, which are free from spaghetti code.

Therefore, the striking aspect of the CBD of physical products is – no spaghetti code/design – about 90% of the features and functionality is implemented in replaceable components, where a replaceable component means a component that can be disassembled for redesigning it individually and re-assembled after testing in outside of the product.

Therefore, a real CBD for software can be defined as: implementing over 90% of the features and functionality in replaceable components (or real software components that are equivalent to the physical functional components). How can we invent real software components that are capable of achieving real CBD for software? One way is to discover the sticking characteristics uniquely and universally shared by each and every known physical functional component. Unfortunately every software researcher insisting that it is impossible to achieve real CBSD by refusing to learn the simple truth, which is otherwise obvious.

The software researchers have been pursuing fantasy and goals that are impossible to achieve such as software-ICs, reusable or standardized components for 50 years. Designers of no physical product achieved the goal such as software-ICs, except computers and cell-phones because they are using not the core components (e.g. CPU or DRAM) but the software (e.g. OS and apps) for competitive differentiation. How do they imagine that it is possible to build software by assembling COTS (Commercially off the Shelf) components, when designers of no other physical product (where software can’t be used for competitive differentiation) ever achieved such fantasy?

On the other hand, no large physical product failed to achieve real CBD, where real CBD can be defined as, implementing over 90% of the features and functionality in replaceable components. Either complexity or uniqueness (e.g. such as one-of-a-kind prototype of a spaceship or a new kind of experimental jet-fighter) can’t prevent the designers from achieving the real CBD. Each replaceable component is free from spaghetti code, because it can be disassembled to redesign individually and test it independently outside of the product. Since 90% of the design/code is implemented in such components, over 90% of the code/design is free from spaghetti code/design.

Many experts insist that it is impossible to achieve real CBD for software, without ever even trying. In fact, no one even knows or ever heard what real CBD is, but blindly insists that it is impossible. No one ever tried to define what real CBD is or try to achieve real CBD for software. If they tried, they would have achieved within a short time. If anyone disagrees, I respectfully request him to show me proof, if any one ever even tried to define what is meant by CBD for the physical products, for example, what is the true essence and essential aspects uniquely and universally shared by design of any known large physical product.

The DEMO pages in our website (e.g. www.pioneer-soft.com) demonstrates many real-software-components and sample applications, if they want to see the proof that it is possible to achieve real CBD for software. In fact, any one can create real-software-components and hierarchies of replaceable components using our GUI library. And yet many researchers refusing to verify the proof, by insisting that it is impossible to achieve real CBD for software.

The software researchers erroneously concluded decades ago that CBD is using reusable or standardized components and pursued wrong goals such as software-ICs for many decades, but not seceded and will never succeed. So they concluded that it is impossible to invent real CBD for software. Now they are not only insisting that it is impossible to achieve real CBD but also refusing to know the truth about the real CBD (i.e. accurate definition for real CBD).

The well known and irrefutable fact is, for real CBD (e.g. of the artificial kidney or an experimental spaceship), it is not necessary that even a single functional component is reusable, standardized or conforming to any so called component models attributed to so called software components. Their own conformational bias is preventing them from seeing even such simple facts, which are otherwise obvious to even the laymen.

Isn’t it a classic example for extremely smart expert behaving like a dumb person? How can I get through him and make him validate the truth – physical evidence. We can provide any help he needs to build hierarchies of replaceable components (e.g. http://www.real-software-components.com/CBD/City_GIS.html) on his own to experience the truth firsthand. I made this offer countless times to hundreds of researchers.

Let me conclude this long post by quoting Galileo’s famous letter to Kepler:  "My dear Kepler, I wish that we might laugh at the remarkable stupidity of the common herd. What do you have to say about the principal philosophers of this academy who are filled with the stubbornness of an asp and do not want to look at either the planets, the moon or the telescope, even though I have freely and deliberately offered them the opportunity a thousand times? Truly, just as the asp stops its ears, so do these philosophers shut their eyes to the light of truth."

            I can’t understand, why smartest and accomplished scientists and researchers even in 20th century, behaving not much differently from the principle philosophers (i.e. scientists were referred to as philosophers) in the dark ages.

Best Regards,

Raju