It is impossible to find a solution to any problem, if there is a mistake in the statement of the problem

Please assume a large algebraic equation is written on the black board for a take home mathematics exam. What would happen, even for the most brilliant student, if he makes a small mistake in copying the equation to his note book (e.g. in a digit or a letter)? I am sure it ruins his weekend, if he hasn't suspect possible mistake in the equation after struggling for several hours and until try to correct it, for example, by calling his classmates for checking the equation.

He can’t solve the equation (without fixing the mistake), even if he uses every method in the books and struggles for weeks. Can software researchers afford to do the similar mistake and struggle for few more decades by using every method in the books or by inventing new methods not in the books? He can’t solve the equation, because there is no solution (due to the error). Scientific problems having error are like the equation having an error. For example, mankind could not have found a solution to Geocentric-model, even mankind struggles for another 1000 years. Today software researchers have been making the same mistake by struggling to find a solution to a problem that has no solution.

For example, Dr. Brooks persuasively argued in his famous book “Mythical Man Month” and in his seminal paper "No Silver Bullet — Essence and Accidents of Software Engineering" that there is no solution. He is right, only because there is an error in the statement of the problem. When researchers discover the error in the equation, it would be apparent that 80% of the effort is not essential cost but accidental cost (so can be eliminated). There is no spaghetti code in the CBD-structure of physical products. But today even small software applications having just 3 SCCs begins its life as a spaghetti code (for example, assume City_LandMarks of City_GIS having three sub-components is a small application). And large applications comprise of hundreds of SCCs.

Unfortunately software researchers have been working vary hard for decades to advance software engineering and CBD for software by relying on axiomatic assumption that each kind of software components is a kind of useful software parts by definition or convention either (i) having given useful properties (e.g. reuse or standardized) or (ii) conform to a given so called component model.

        The above is a huge error, for example, in light of 2-CBD-facts and 3-CBD-rules. This error wasted (i.e. ruined) many decades of research effort on component based design. The software industry is wasting tens of billions of dollars each year on creating and managing spaghetti code (e.g. Big Ball of Mud).

Yet many experts refuse to even consider possibility that, there might be a small mistake in using term “software components” as synonym to “useful software parts”, by definition or consent of recognized committees either (i) having certain properties or (ii) conform to certain so called component-model. In case of physical products (see 3-CBD-facts), no other kind of physical parts can be a component except very specific kind of physical parts having very unique set of properties, where the components are essential to achieve real-CBD.