Humbly requesting software researchers to not forget sacred duty to pursue Truth by relying only on substantiated concepts and facts

Any real scientist must agree: the scientific progress is discovering new facts for expanding the boundaries of human knowledge. Pursuit of the absolute truths (or facts) is the basic responsibility and sacred duty of each and every real scientist or researcher. Unfortunately, many software researchers ignored or forgot this basic sacred responsibility.

Please kindly don’t forget basic scientific principles: Any real science ends up in a contradiction or paradox if and only if there is an error in the basic facts, concepts and reasoning. It is an error to rely on any subjective concept or axiom without sound basis in reality and fact, since any error certainly leads to a paradox. It is a huge error.

"By denying scientific principles, one may maintain any paradox" ---Galileo Galilee

The real scientific progress depends on researchers pursuing Truth (objective facts) with passion, since no real scientific progress is possible by relying flawed subjective concepts or erroneous postulations. Any scientific field sooner or later ends in a crisis, if scientists abdicate this sacred duty (e.g. not validating baseless axiomatic assumptions or unsubstantiated postulations).

Unfortunately, software researchers have been trying to advance software engineering by relying on a flawed root postulation since 1970. This error must have a cost of a trillion dollars to the world economy (so far). Each and every concept in computer science can be and must be objective facts, but today computer science ended up with many subjective concepts (many of them contradict reality) due to this erroneous root postulation: http://www.real-software-components.com/more_docs/SummaryAs3facts.html

Stating the fact that “the Sun is at the center” offended common sense or insulted deeply entrenched collective conventional wisdom of respected scientists 500 years ago. Likewise, unfortunately few software researchers might feel offended, when I try to point out certain errors. At any time since 1970s tens of thousands of researchers have been working very hard (e.g. applying brute force) with passion for advancing the software engineering by relying on this unsubstantiated flawed root postulation (without ever validating or even aware of the huge error). This brute force resulted in evolution of complex paradoxical paradigm with ecosystem comprising 3-dimensional web of interdependent concepts (many of them are no different from epicycles& retrograde motions resulted form the error in the root postulation).

Please kindly remember, the software engineering paradigm has been evolving since 1968 (resulting in deeply entrenched conventional wisdom and a huge ecosystem of interdependent concepts), by relying on this huge undetected error. Mankind not made this kind of error in basic seed axiomatic premises, since exposing the error of then deeply entrenched Geocentric-paradigm 400 years ago. Please kindly remember, it is invalid circular logic to use any concept (e.g. epicycles and retrograde motion) derived from geocentric-paradigm to discredit heliocentric-paradigm.

Can we even imagine designing and building complex one-of-a-kind products such as Jet-fighters or spacecrafts without componentization (i.e. partitioning into a CBD-structure or component-hierarchy)? No component in the hierarchy magically works perfectly at first attempt. Each component is refined or redesigned little-by-little to make it as best as it can be (in CBD-process step-1). This process of refining and redesigning each component would continue throughout the evolutionary life of the product-family, for example, as summarized in step-3. For example, consider design and development of a new innovative product at:

          It is impossible to find a valid reason why each of the complex software products can’t be design as component-hierarchy (i.e. as a CBD-structure), where each component can be evolved individually outside of the product, especially in light of the following two important irrefutable facts about CBD of the complex physical-products (henceforth referred to as 2-CBD-facts):

1.    It is an obvious fact that, it is not necessary that even a single component in the component-hierarchy of a product (e.g. a spacecraft or experimental Jet-fighter) conform to so called component models or have any property (e.g. reuse or standardized) erroneously attributed to the any kind of software components known today.

2.    We also know that either uniqueness or complexity of one-of-a-kind products (e.g. a spacecraft or experimental Jet-fighter) can’t prevent designers from achieving component-hierarchy (or CBD-structure).

It is an irrefutable fact that: the cost of disassembling or reassembling any complex CBD-product is under 5% of the cost of designing and building all the components of the complex CBD-product (in step-1 or step-3 of CBD-process). In light of this fact, why isn’t it possible to design each of the complex software products, so that the product try to satisfy the following three rules (hence forth referred to as 3-CBD-rules) by inventing real-software-components that are logically equivalent to large physical functional-components:

1.    The application must be built by taking a bare application template and assembling all the components, where no component need more than 2 to 5 lines of code to assemble.

2.    Removing the 2 to 5 lines must effectively remove the component and removing all the components (one component at a time) result in the original bare application template.

3.    Once all the components are ready, the product can be disassembled or reassembled for about 5% of the cost of designing and building all the components in the component- hierarchy.

After building hundreds of software GUI-applications each GUI-application (e.g. City_GIS) as a CBD-structure, I can’t find a valid reason why software applications can’t be built to satisfy the 3-CBD-rules. Let me confess that I implemented some custom code in each application template, but the custom code is about 10% of the total application code implemented for all the real-software-components. Hence, this custom code would be left in the template in case of rule-2 and costs up to 15% in case of rule-3. Of course, most of the custom code is implemented to fill gaps for doing certain routine house keeping work and communication code. Based on the earlier experience I learned that most of the custom code can be eliminated by creating and using certain generic reusable components and intelligent CASE-tools targeted at achieving real-CBD for software.

My humble request is to discover innate nature and essential properties uniquely and universally shared by each and every physical functional components, since the essential properties are useful for positively identifying equivalent software components in complex software applications. Although goal must be and can be 100% componentization of each complex application, please keep in mind that, even if 50% of the application code is created as component-hierarchies, each component can be redesigned and tested outside of the application individually at a fraction of the cost and time.