Rather than asserting software CBD is a deviation, please consider the full historical industrial context.  Ultimately, you are talking about architecture.   Architecture is about standards and practices.  Software architecture is in an early evolutionary stage.

Starting with the architecture of the pyramids and the aqueducts, design decisions have always reflect the intent to create a physical object that serves a purpose.   The purpose infers the solution - form follows function.

Mechanical CBD practices flowing from replaceable parts are hundreds of years old, and based on very practical, physically measurable concepts of form, fit and function. The machine has to be able to be assembled, therefore clearances must be met and mating sizes must match to tolerance.  The load to be lifted dictates the strength of the members, and so on.

Following on with the introduction of mechanical factory systems driven by steam and then electricity into the design of physical goods, the mathematics of energy handling were added to the calculations of size and strength.  Electricity began the introduction of "virtual" factors, particularly with invisible but measurable qualities such as resistance and inductance.

In all cases, the requirements of the finished product can be expressed in purely quantifiable mathematical terms.  Thus, components can be devised, functional boundaries created and specified in minute detail, and the characteristics of components relative to each other can be optimized mathematically to meet specified performance criteria.

Compare this with the field of software engineering.

First: Software Engineering is only a few decades old.  The practice of the art continues to evolve.  Was component-based design invented and perfected with the advent of machine tools?  No.  In fact, it CBD continues to evolve today with advancements in materials science.

Second, software relies fundamentally on uncontrolled factors which change after the design and manufacturing of the software itself has been completed.  While we may target a particular processor architecture, and specify a minimum processing capacity in terms of working memory or storage space, these fundamental aspects of the software product are variable.  There is no analog to this in manufacturing... Certainly, the environment (such as power source, temperature, or atmospheric pressure) a mechanical component is subjected to can vary, but the substrate materials of a manufactured good do not fundamentally and arbitrarily change after production (other than natural age-related decay of materials, which can also be mathematically described in any case.)  Contrast this with software, which is deployed into an environment of constantly evolving processors and platforms.  The target can be modeled - but it is not controlled.  Software components, therefore, cannot be fully and accurately mathematically described.  The solution can only be partial.

Thirdly, software is fundamentally subject to psychological factors both during the manufacturing process, and in use after release.  We are dealing with humans here. Humans are simply not mathematically quantifiable. The "best" componentization strategy will always reflect the experience of the designer, and their insights into the desired lifecycle characteristics of the software product under construction.  There are many desired characteristics which fundamentally conflict.  For example, designing for both universal processor portability and simple maintainability are fundamentally conflicting requirements.  The designer will make compromises, which in turn influence or dictate the componentization strategy. 

Psychologically then, consider the fact that componentization naturally requires modularization.  In software, modularization adds complexity, by imposing arbitrary abstraction on the structure of a software product.  Depending on the modularization strategy, some things will become easier to implement, while others will become much harder. Thus, one of the determinants of design is labor efficiency in production. Monolithic software construction can be more efficient to produce and operate, but eliminates flexibility and can introduce unforeseen performance limitations.  Proper design will strike a balance.  Components are not an end in themselves.

In short, there are so many uncontrolled variables in software manufacturing that the practice of CBD cannot work unless severe constraints are put in place.  One can cite examples from the field of embedded control software, in which the target processor is firmly fixed, the inputs and outputs are clearly specified, and the product can be mathematically described.  This is the rare exception.  Most software of any complexity (requiring a component strategy) will be targeted towards some more general business need and have a longer design life-cycle across numerous releases.

However, in this respect we run into the final obstacle: Business needs also change. Businesses are loathe to impose severe constraints, because this limits future opportunity.  Software production is expensive. In order to ensure that the investment will provide a reasonable return, businesses try to ensure a longer lifecycle for the software. This in turn extends the uncontrolled variables further into the future, lessening the ability to calculate an optimal componentization strategy.

So in conclusion, the attempt to formalize software CBD will succeed when a mathematical model is constructed which can reconcile a) the changing needs of business, b) the evolving computation environment of the target devices, c) the psychology of the team members producing the software, and d) the psychology of the end-users operating and consuming the software.

The good news is... with all this computational power lying around, such a formula is actually conceivable!

 - RTC

Dear Mr. Carpenter,

            Thank you for long answer. You just explained the compelling need for components and need for eliminating the spaghetti code.

            Let me give you an example – an application created by assembling real software components as hierarchy of replaceable components: http://real-software-components.com/CBD/City_GIS.html

            In the above sample application that achieved real CBSD, over 98% of the application specific code is implemented in 6 components. No component requires more than 3 to 5 lines code to plug-in to the application. So each component can be effectively unplugged (without leaving any traces) by removing the same 3 to 5 lines of code.

            If I am responsible for a component “City_ATC”, I don’t need to see even a single line of code implemented for any other component or part of the application. If I need to add features or fine-tune functionality “City_ATC”, I can do that and test it individually. This is true for each of the 6 components.

            For example, if you join my company and our manager asked you to add new features to “City_TouristSpots” you can find all the code base for this component in an exclusive folder. You can run it as an individual application by creating a just a simple application. You can redesign the component and test it individually. When you satisfied with it functionality or features, you can plug it into the application.

            If you changed any coupling-interfaces inadvertently, our intelligent  CASE-tool http://real-software-components.com/CBD/Sample_SoA_CASE_tool.html catches the bug, so that you can take necessary actions, such as talking the developer responsible for the other component, for example, to adjust the parameters for the interface function used for collaboration between the components. You can accommodate all the factors you mentioned.

            But unfortunately, today no such component is identified to build as a replaceable component. So you need to spend many hours even to locate code sections for “City_TouristSpots” in many non exclusive files (where the non exclusive files contain code sections for more than one such components and parts).

            Even one were able to identify such component having few dozen 2D/3D GUI components, no other GUI-API (e.g. Windows/VC++ or Java/Swing) is capable of encapsulating the code implemented for the component in a replaceable class definition.  So we are forced to create each component as a spaghetti code, by implementing its code sections in non-exclusive files.

            Mr. Carpenter, design of every new complex product (e.g. an experimental spaceship or prototype of a new Jet-fighter) endures all the factors you mentioned. Why do you think, it costs billions of dollars to build first fully working prototype (golden version before mass production)?  This doesn’t prevent any one to disassemble any component to refine and test it individually out side. Over 98% of the features and functionality is implemented is such replaceable custom components.

            Once the product is released, the product is evolved by evolving each of the components individually as summarized in step-3: http://real-software-components.com/CBD/CBD-process.html

            They were able to do all this for each of the components without suffering consequences of spaghetti code. I believe, any application can be implemented as a hierarchy of replaceable components, once the accurate description for the physical functional components. It is not hard to identify parts (equivalent to the physical functional components by satisfying the description) to design as replaceable components. Of course, it is not hard to redesign other GUI-APIs to allow encapsulating such components as a replaceable component class and I already have such GUI-API.

Best Regards,

Raju

Dear Mr. Vergne,

            I know, I am going against deeply entrenched conventional wisdom, but I believe (based on my experience of creating hundreds of replaceable components for many years) that it is not hard to invent such reliable abstraction.

            But pre-condition for finding the reliable abstraction is discovering the accurate description for the physical functional components. It is not trivial task to discoverer the accurate description for the physical functional components, but it is not impossible either.

            I am sure, any good engineer can discover the accurate description for the physical functional components, if he start investigating, for example, to discover the essential properties uniquely and universally shared by each and every known physical functional component. It may take few days to couple of weeks of hard work, but it is possible. For example, I used the method summarized at: http://real-software-components.com/RSCC/accurate_description_for_CP.html

            Once the essential properties are discovered, it is not hard to identify potential “self-contained functionality/features” (when looking at the requirements of the application), which can be implemented as a replaceable component classes.

            If he does a good job, it is not impossible to encapsulate 97% of the functionality and features of the application in replaceable component classes. Today not even 5% of the custom features and functionality is implemented as replaceable components, but I believe, even a junior programmer can encapsulate at least 30% of the features and functionality in replaceable components, if he spends few weeks to discover the essential properties (i.e. the hidden reality about the physical functional components).

            Just like, OOA (Object Oriented Analysis), identifying certain kinds of components for implementing certain kinds of feature and functionality is easy. For example, identifying “self-contained functionality/features” in GUI application is much easier than identifying “self-contained functionality/features” in a compiler.

            For example, I believe, you or any one should not have any problem in discovering the essential characteristics, if you put sincere effort for few days. I am sure you would agree with me, if you discover the essential characteristics.

            Today, no one is acknowledging remote possibility of an error in the definitions of software components. For example, 500 hundred years ago, no one even acknowledged remote possibility that the Earth is like any other planet and might be moving. So no one even tried to investigate the Truth. I am sure, hundreds of researches could have discovered that the Sun is at the center, if they try to investigate the Truth. So the greatest contribution of Copernicus is not discovering “the Sun is at the center”, but shedding light on unknown first principle “the Earth is static” at the root of geocentric principle: https://www.researchgate.net/post/How_many_experts_researchers_know_answer_and_or_agree_with_my_answer_to_this_question_What_is_the_greatest_scientific_contribution_of_Copernicus.

I am sure no one believes that “5*5=25” is an assumption. No text book or any paper mentions such facts. Similarly, no one imagined that “the Earth is static” was an assumption (that was presumed to be a fact). Similarly, 50 years ago they might have believed that it is impossible to invent software components equivalent to the physical functional components. My humble opinion is, such undocumented hidden assumptions (i.e. first principles at the root of existing CBSD paradigm) no longer valid.

Best Regards,

Raju

Dear Mr. Vergne,

            I believe, any one can discover the accurate description for physical functional components and accurate description for the CBD of physical products within few weeks (at most couple of months (if he tries hard enough).

            I believe, this is not hard task (but not trivial either to do it in few hours). Let me define few terms:

Our first principle-1: There exists an accurate unambiguous objective description for the CBD (Component Based Design) of physical products and it is possible to discover accurate unambiguous objective descriptions for the CBD of physical products.

            My research effort spanning years resulted in discovery of a set of essential aspects uniquely and universally shared by each and every know design of one-of-a-kind physical product (e.g. an experimental prototype or a newly invented product) that is created by assembling physical functional components.

Our first principle-2: There exists an accurate unambiguous objective description for the physical functional components and it is possible to discover accurate unambiguous objective descriptions for the physical functional components.

            It is not impossible to prove that, there exists one and only one accurate description (i.e. absolute Truth) for the physical functional components. Even if it is not possible to discover the absolute Truth (i.e. accurate description), it is certainly possible to discover an accurate description (that is close enough to the absolute Truth) for the physical functional components. My research effort spanning years resulted in discovery of an accurate description (that is close enough to absolute Truth for most of the practical purposes) comprising a set of essential properties uniquely and universally shared by each and every physical functional component known to mankind.

            Henceforth the term ‘real-software-components’ implies a very special and unique kind of software parts (or modules) that are equivalent to the physical functional components by having the essential properties, where the essential properties (or characteristics) means the set of essential properties uniquely and universally shared by each and every known physical functional components.

            It is not impossible to prove that, there exists one and only one accurate description (i.e. absolute Truth) for the CBD of the physical products. Even if it is not possible to discover the absolute Truth (i.e. accurate description), it is possible to discover an accurate description (that is close enough to the absolute Truth) for the CBD of the physical products. My research effort spanning years resulted in discovery of an accurate description (that is close enough to absolute Truth for most of the practical purposes) comprising a set of essential aspects uniquely and universally shared by each and every CBD of the physical products known to mankind.

            Henceforth real CBSD (CBD for software products) implies a special and unique kind of CBSE/CBSD that is equivalent to the CBD of physical products by having the essential aspects, where the essential aspects means the set of essential aspects uniquely and universally shared by each and every known CBD of physical products.

            Just like mankind’s scientific knowledge about many of the physical beings (or spices) and phenomena, each of the above accurate descriptions can be iteratively improved to advance our knowledge about the physical functional components and the CBD physical products closer and closer to absolute Truths.

            Mr. Vergne, if you were to look in books and papers 600 years ago, you could not have found any mention of the first principle “the Earth is static”. They would be describing retrograde motions and resulting epicycles. None of them were consciously aware that they had been evolving the “reality” (i.e. perceived reality) for thousands of years by relying on an unknown first principle “the Earth is static”.

            Today, it is impossible to find reasons why definitions for software components and CBSD deviated from the reality. For example, let me mention couple of irrefutable facts about the reality about the CBD of physical products and physical functional components:

(i)                 about 97% of the features and functionality of a physical CBD product is implemented in components, which are assembled as hierarchy of replaceable components as in FIG-2: http://real-software-components.com/CBD/CBD-structure.html

(ii)               It is not necessary, not even single component in the component hierarchy need to be reusable, standardized nor properties do we erroneously attribute to the so called software components.

Mr. Vergne, reuse is software engineering’s epicycle. It is not necessary for the components to be reusable. In fact, over 90% of the core components are custom designed for products such as Camry or Accord. For example, using engine from red Camry in Blue Camry is not reuse. We can’t assemble Camry engine in a Corolla. Each component is custom designed for a product model.

We in software are trying to reuse components from compiler product family in another product family such as product families Video games or spread-sheet. This is like, trying to reuse core components of automobile product family in another product family such as cell-phones or Air-conditioner. But product models for all the CBD product families contain ‘hierarchy of replaceable components’.

Mr. Vergne, trying to advance mankind’s knowledge (by relying on wrong first principle ‘the Earth is static’) resulted in altered reality – paradoxical paradigm. Exposing the error in the first principle put the scientific progress on the right track.

My humble opinion is, any one can discover the truth within few weeks, if they tried hard enough. I believe, spending few weeks is not hard task. I invested more than a decade to collect all the information and placed openly in my website real-software-components.com for any one who wants to try.

When I told this to my friends and former colleagues in Silicon Valley, they asked me to prove it by building their applications as hierarchy of replaceable components. So now I am forced to start a company pioneer-soft.net to assist them in building their applications as hierarchy of replaceable components. I am sure, not even a single component in the hierarchy would be reusable or have any properties erroneously attributed to the so called software components.

Although I created hundreds of component hierarchies (to prove for my self) and had time to demonstrate only few of them on my laptop in short presentations, they wanted to know, if it can solve their problems. Hopefully within a year, the team I am building now will be ready to help them (and you, if you want) to create any of their GUI applications as a hierarchy of replaceable components. We are planning to provide this kind of services for free of cost until we can prove our discoveries and inventions to few friends and companies.

We planning to providing our GUI API and source code for free to try (i.e. free of cost for one year), so that any one can build replaceable components such as: http://real-software-components.com/CBD/City_GIS.html . Hopefully this would help overcome skepticism by providing irrefutable first hand empirical evidence.

Best Regards,

Raju

Dear Mr. Vergne,

            The interfaces don’t need to be reusable. They need to be loosely coupled. The physical functional components by nature loosely coupled. It is their inherent nature, and that is the reason each of them can be easily unplugged and re-plugged.

            Furthermore they are conducive for automation. So it is possible to invent CASE-tools such as this one: http://real-software-components.com/CBD/Sample_SoA_CASE_tool.html

            Please review the FIG-3. The purpose is to automatically detect any incompatibility created in coupling interfaces during redesigning. The objective is to minimize the cost of redesigning the components and their interfaces.

            What would you do, if you need to change interfaces of a physical component to add certain new features? You ask the designer of the container component to redesign its interfaces, so that they can continue to work together. Why software components be any deferent?

            Please try to understand designing of any new product. Kindly allow me to provide an example: http://real-software-components.com/CBD/CBD_of_new_product.html. I am referring to my one pages, because this kind of information is not available anywhere.

            None of the components are reusable. None of the interfaces are reusable. I am sure, the interfaces are frequently redesigned in collaboration with designers of other components that are connected by using the interfaces.

            Yet, 98% of the features and functionality is implemented as replaceable components, where each component is designed and tested individually (to make its as best as it can be) before assembling to test the product. If an interface between two components doesn’t fit, interface of one of the components is redesigned. These are the objective irrefutable facts, we all know. All I have been stating is simple facts, we all knew in the context of CBD of physical products.

            Mr. Vergne, if you understand the history and complexity of exposing an error in a first principle at the root, you would not say this kind of statements. I can give, so many examples, such as: http://real-software-components.com/forum_blogs/BriefSummaryOfTruths.html#Chronology.

No body took Copernicus, Kepler discoveries seriously until decades after their death. It didn’t prevent them from saying, what they believe to be Truth. I am referring to my own pages, because this kind of information is not available anywhere.  If you disagree or find any flaw, you are free to show me, such as: http://real-software-components.com/misc_docs/EvolutionOfUsefulThings.html and http://real-software-components.com/RSCC/ecosystem-evolution.html

Keplers laws provided insanely accurate description (extremely close to absolute Truth) for the planetary paths. I am sure many experts felt that he was making up them. But his decades of effort, I am sure, he knew he was absolutely sure. But now we all agree he was right. No one can make up such accurate laws. Even if you don't like the word 'impossible', it is impossible to make up such laws by waking up one day and guessing.

Why are you obsessed with reuse? Most of the components are not reusable. But each component can be refined free from spaghetti code. Since 98% of the code is implemented as components, 98% of the application code can be free from spaghetti code. Since the product is evolved by evolving each of the components individually, the application can be free from spaghetti code throughout the evolutionary life.

Best Regards,

Raju

Dear Mr. Vergne,

            All I am saying is, any one can discover essential properties uniquely and universally shared by each and every known physical functional components within few weeks (at most).

            That is, no physical part can be a component without having the essential properties. And any physical component can no longer be a component, if it loses any one of the essential properties.

            If this above is right: It is wrong to define any other kind of software parts (without having the essential properties) is a software components, if it is possible to invent real software components having the essential properties.

            So far no effort is made to prove such essential properties don’t exist. It is wrong to blindly define the nature and properties of software components, without such proof. They assumed 50 years ago software is different and defined many kinds of so called software components. I am sure, those assumptions no longer valid.

            If you were to ask any one 1000 years ago, they would insist planets move in epicycles and they observed countless retrograde motion as an irrefutable proof. They don’t know (and would refuse to accept) that they are making a wrong assumption that “the Earth is static”. They were not aware, that they are relying on this first principle. In fact, saying “the Earth is moving” would offend common sense and deeply entrenched conventional wisdom.

            Please don’t forget the context and background for this thread. Please see my question at the top. I asked why we need to deviate from the reality of physical functional components. I have no objection, if there is a proof to show, that it is impossible to discover such essential properties for the physical functional components. Without such proof, software engineering evolved for 50 years by relying on a fundamentally flawed assumption, no different from the assumption “the Earth is static”.

            No observation and reasoning is valid. To justify the anomalies and contradictions, we are making all the mistakes outlined by Karl Popper (copied from wiki pages): Popper is known for his rejection of the classical inductivist views on the scientific method, in favour of empirical falsification: A theory in the empirical sciences can never be proven, but it can be falsified, meaning that it can and should be scrutinised by decisive experiments. If the outcome of an experiment contradicts the theory, one should refrain from ad hoc manoeuvres that evade the contradiction merely by making it less falsifiable. Popper is also known for his opposition to the classical justificationist account of knowledge which he replaced with critical rationalism, "the first non-justificational philosophy of criticism in the history of philosophy."

The retrograde motion and epicycles are absolute Truths, if “the Earth is static at the center” is an absolute Truth. Likewise, all the existing concepts (i.e. retrograde motion and epicycles of CBSD) are irrefutable facts, if there is a proof that it is impossible to find such essential properties for the physical functional components.

Over 70% to 90% of the concepts and observations of existing CBSE would be invalidated, when and if it is possible to discover accurate description for the physical functional components. For example, over 90% of the knowledge (concepts and observations) of geocentric paradigm (accumulated for 1000 years) were invalidated, when the error was exposed. There can't be any exception for the first principles at the root of any scientific discipline including computers science, weather any of the first principles are known or unknown.

Best Regards,

Raju

Dear Mr. Vergne,

            Obviously we are not going anywhere. For first question, just search for “software components” in Google. Read any book on CBSE, such as Component Software: Beyond Object-Oriented Programming by Clemens Szyperski.

            For second questions, if you can find any scientific evidence that planets are not going around Sun. You would be the most famous discoverer in the world. Mankind no evidence to falsify the Copernicus discovery in 500 years.

            For fourth question, I have been asking, why no one can name first principles that lead to bad definitions for components, without any basis in reality?

            Do you have any proof that reuse is the essential property of the components, since you implied reusable parts are components?

            To get genuine orange juice, you need to squeeze genuine oranges. You can’t get orange juice by squeezing any other kind of fruit. Likewise, genuine CBSD requires using real software components. It is simple reasoning.

            Can you show me any existing software component that can achieve real CBD, where real CBD requires implementing about 90% of the features and functionality as replaceable components?

            I am openly offering to show physical evidence that I created hundreds of components and component hierarchies to demonstrate that it is possible to achieve real CBD, such as:http://real-software-components.com/CBD/City_GIS.html. By the end of this year, our team can build any application as hierarchy of replaceable components, if any one asked us to prove it by building their application as hierarchy of replaceable components.

            It was impossible to find even a single reference to support that the Sun is at the center 500 years ago. People eventually accepted physical evidence over the scriptures. Today I can show hundreds component hierarchies. Next year our team can build any of their application by assembling replaceable components, if they are willing to see physical proof.

            I believe, no one can deny, if a large application like MS-Word is build as hierarchy of replaceable components (where 90% features and functionality is implemented in replaceable custom components). We will proof whoever is interested in seeing the proof. We can only offer but can’t force any one to see physical proof.

I am relying on physical proof. For example, today no other GUI-API is capable of encapsulating code base for self-contained component such as City_ATC in a replaceable component class definition (and a set of exclusives associated with the class). Hence each of this kind of component begins its life as a spaghetti code. That is, code implemented for including this component in any application ends up in non-exclusive files. If any application has 100 such components, this is true for each of the components. It is impossible to refine this component without seeing code implemented for other components. I can show you this proof today, if any one gives me an opportunity.

Best Regards,

Raju

Dear Mr. Vergne, 

            I can’t publish physical proof. I can only show physical proof. I can only offer, but I can’t force any one to see physical proof.

I can teach any one to create GUI API that is capable of encapsulating large GUI-application in a replaceable class. I can only help them to create such GUI API by providing basic source code. That information is openly and readily available in the US patents 7827527, 7840937 and 8527943.

Also the US patents 8,392,877 and 8,578,329 describe method for discovering essential properties of physical functional components for identifying real software components to achieve real CBSD.

I can only offer, but I can’t force any one to see physical proof.

I am sure you or any one can discover essential properties uniquely and universally shared by each and every known physical component within wakes. I can only request, but I can’t force any one to discover Truth by using method outlined at: http://real-software-components.com/RSCC/accurate_description_for_CP.html

Best Regards,

Raju