|
Practical Knowledge & Intellectual Knowledge for real CBD/CBE
|
|
Example for practical Knowledge: If I drop a stone from top of a building, I know that it falls on the ground. Anyone can observe a stone falling on the ground by dropping the stone from height. Mankind didn’t have scientific explanation until 17th century, why stone falls on the ground when dropped form hieght. Example for intellectual Knowledge: If I drop a stone from top of a building, I know why it falls on the ground, because I learned Newton’s discoveries and mechanics when I was in school and college.
|
|
The observations such as epicycles and retrograde motions of planets were practical knowledge, because anyone living on the earth can observe epicycles and retrograde motions. Mankind didn’t acquire intellectual Knowledge until 17th century, why planets appear to be making epicycles and retrograde motions. The scientific explanation in 17th century proved that the epicycles were illusion. This proves mankind can be fooled by practical knowledge or perception alone. Our perception of reality and things we experience in practice might fool us. We need intellectual knowledge or scientific explanation to determine the degree of falsity of knowledge and Verisimilitude (or truthlikeness). |
|
Our practical knowledge or perception of reality might be an illusion and flawed, if we can’t provide valid reasons why it happens that way, or why things behave the way they do. How can we be sure that our perception of reality or practical knowledge is valid until gaining intellectual knowledge, scientific or logical explanation of why? Today only designed of software products have been experiencing the infamous software crisis and spaghetti code/design. No one knows why, designers of no other kind of product effected by similar crisis? |
|
Mankind has practical knowledge that the design, engineering and development of no other kind of products (except software products) is affected by spaghetti code/design. Neither complexity nor uniqueness of one of a kind product (e.g. building a working prototype of a next generation Jet-fighter, nuclear powered locomotive engine or spacecraft) can force the designers or engineers of the product to endure spaghetti code/design. |
|
|
Mankind didn’t have intellectual Knowledge or rational explanation, why designing, engineering and building of any other product is not affected by spaghetti code/design (or crisis similar to infamous software crisis). Gaining intellectual Knowledge help invent solutions, necessary tools, processes and mechanisms for eliminating spaghetti design/code (and the infamous software crisis) from designing, engineering and building of software products as well. |
|
|
As one can see, gaining intellectual knowledge about “why stone falls on the ground” helped us advance our knowledge. Likewise, I am sure that the infamous software crisis can be solved by gaining intellectual Knowledge about “why design of no other product is affected by infamous software crisis and spaghetti design/code”. The fact is, there is no valid reason why software engineering alone must endure infamous software crisis and spaghetti code. |
|
How can I compel software researchers to acquire such intellectual knowledge or logical explanation, which I am sure leads to solution for the infamous software crisis and spaghetti code? Our perceptions or experiences could fool us. The practical knowledge and intellectual knowledge complement each other. Both are essential and our knowledge can’t be complete, if one of the knowledge is flawed, invalid or missing (i.e. not yet available). |
|
Total cost of ownership of a product can be divided into two main parts (1) total cost designing and building, and (2) total lifetime cost of operation and maintenance. If a large or complex product can be built by literally assembling (or plugging-in) many optimal size components, then the total cost of ownership of the product includes sum of total cost of ownership of all the components. It is simpler not only to design and build but also redesign and test each smaller component individually (outside of the product). Hence, the total cost of ownership of the product can be reduced by reducing the total cost of ownership of each of the components (i.e. parts that can be unplugged and re-plugged-in). |
|
The cost of designing and building each of the components can be minimized by maximizing reuse. Total lifetime cost of operation and maintenance of each component can be minimized by minimizing the cost of disassembling (e.g. to replace it or to redesign it individually outside of the product) and re-assembling (after testing it individually our side of the product). Today not even single software product is created by assembling components. |
|
About 80% lifetime cost of operation and maintenance can be eliminated by designing building software products using custom parts that can be literally assembled. If real components are defined as spherical kind of parts that are designed and/or conducive to be literally assembled, such real components for software are not yet invented. For example, each software application contains dozens of large parts that can be designed to be assembled (or plugged-in), but not even a single such part is designed to be assembled (or plugged-in). |
|
Each large software application contains many dozens to few hundreds of parts that can be designed to be assembled (or plugged-in). For example, consider a GIS (Geographic Information Systems) application City_GIS may contain several dozen parts such as City_ATC (Air Traffic Control or Monitoring System) or City_ER (Emergency Response), each of which can be designed to be assembled http://www.real-software-components.com/CBD/City_GIS.html. Almost every component such as City_ATC requires implementing several hundreds to few thousands lines of custom application code, even after maximizing reuse to minimize the custom code. The total lifetime cost operation and maintenance of City_ATC can be minimized by implementing the custom code as a plugable component, so that, it can be unplugged to redesign and test individually outside of the product free from spaghetti code. |
|
|
|
Copy Right © 2013 SPPS Systems Pvt.Ltd. All Rights Reserved.
This Website presents patented and patent-pending Inventions and Discoveries |
|
|