Back Ground: The ‘Component-oriented’ programming is absolutely essential to overcome the ‘software crises’. This process comprise of building ideal loosely coupled interchangeable custom components and assembling the components to build larger and larger interchangeable components (i.e. build component-hierarchies). This webpage gives an example to show: If it were not possible to build loosely-coupled parts and then build hierarchies of swappable modules (Useful), the product-makers, such as computer-makers, would also face similar crisis, no different from the software-crisis.

Each application contains many 'loosely coupled' components. However the OOP (Object Oriented Paradigm) don't partition the application into physical “loosely coupled” parts. That is, the OOP don't physically separate the 'Loosely coupled' parts and physically encapsulate each loosely-coupled component in a unit (e.g. CF) to preserve its autonomy, for example to operate on the unit autonomously. Just recognizing their existence and consciously reorganizing the application into “loosely coupled” parts would more than double the average software developer’s productivity.

Many Objects are used to build each “loosely coupled” part. Hence the “loosely coupled” parts are higher-level abstraction. Also each “loosely coupled” component needs minimal coupling code to include into the application. All the applications contain many “loosely coupled” components, but unfortunately often it is not possible to leverage them in the traditional programming paradigms such as OOP.

For example, assume a small application has only two parts. One ends up creating set of files and each of the files contains Object for each component. But, if you study the interactions between these two components, they may have about 10 to 15 lines of coupling code, with out any conscious optimization. With very little effort or slight redesign, it is possible to reduce the coupling code to about 5 lines.

Figure#1

To study this, virtually partition the Objects into 2 sets on a paper: Set-A & set-B (see FIG#2). Here, each set contains Objects used for building each component. Then map the interactions (Red Arrows) between the two groups and count lines of code.

Figure#2

Each black-arrow shows the dependencies between the Objects used for building each component. The red-arrows shows dependencies between the components (i.e. Interactions between any two Objects, where each Object belong to two different components). Even each 'Component' is not optimized consciously to minimize its couplings, most "Components' would have very little real-couplings with rest of the parts as shown in FIG#2.

However, the OOP do not encapsulate each Object-group to maintain physical separation between the Object-groups (i.e. component-abstraction). Hence, to separate the component from the application, it requires lot of manual-effort and knowledge about the internal design of each component, such as, to identify each of its Objects, interactions between these Objects and with external Objects.

This is kind of like, putting both Graphics-card and network card on same board (e.g. PCB- Printed Circuit Boards) by combining all the chips/devices for both parts (See software equivalent in FIG#1, where each Object is a device). How can a new person replace or remove the network card alone, with out identifying and removing each device used for supporting the services offered by the network-card?

Now imagine, if one builds the entire computer like that. All the chips/devices for all the plug-in parts of the computer (e.g. Hard-drive, mother-board, power-supply, floppy-drive and CD-player etc.) are placed on a very large main Printed-circuit board.

Figure#3

Even a trivial conscious design effort could reduce each 'loosely coupled' part's couplings to about two services-level interfaces (which is shown in the right side of FIG#3).

This is just one-level of hierarchy. For example, the hard-drive again contain many subcomponents, where some subcomponents (e.g. Motor that spins the magnetic disks) contain many subcomponents of their own. If the Motor contains 10 devices, one  needs to put the 10 devices on the same main board. The subcomponents (i.e. devices) of the Motor may be placed next to the devices for the CD-player. Again one of the subcomponent of the Motor may have 5 devices, each of which needs to be placed on the same large board. Notice the 'component-hierarchy' in the complex products.

This successive decomposition of subcomponents into basic devices makes its physical structure flat. If all the basic devices for each of the computer-part are placed on a large board, how any one can remove a large part? Please remember each part may contain subcomponents, which in turn contain many device? If one places all the basic devises on large flat-board, it is unlikely or even hard to make any conscious effort to minimize the dependencies (e.g. Red-lines in FIG#2) between the 'parts'.

Likewise, for three large 'parts', the physical structure of the Objects end up as shown Fig#15 in the webpage (while they should be organize as shown in Fig#17)*. So, in the OOP, the physical structure of the Objects end up flat. In such flat structure, to remove or replace a large part, one must remove one tightly-coupled object (or device) at a time. This requires lot of knowledge and expertise, and yet prone to errors.

*Important Figures: You must see how spaghetti-code start accumulating even for 2 or 3 components. ('Physical structure of code beginning to stop reflecting the design-intent' (more later)). Even a medium-size application contains hundreds of components, each of which contains one or two service-interfaces. Hence, in large applications all these Object-level dependencies buried under a million lines of code. 

OOP does not make any distinction between these two kinds of dependencies (represented by black arrows and red arrows). These dependencies together constitute nearly 50% of total application code. If we could make the distinction, the red arrows would constitute about 4% to 7% of the code. A conscious design not only reduces them to less than 2% of the code but also makes it easy to comprehend high-level code.

Although, design document may say there exist some sort of virtual hierarchy, the physical structure of the Objects is undeniable flat (spaghetti code). How can new recruits comprehend such 'highly subjective' imaginary hierarchy? It is too complex to predict what soft of effect a small change would have on the other parts. To make even a small change, he must comprehend internal design and interfaces of many objects. 

Is there any wonder the software development is in crisis?
Proof: One more example to illustrate the source for the 'software-crisis'

Each large application contains many such components, and subcomponent hierarchies. Pioneer-soft invented an elegant way to encapsulate each component in a Replaceable Container, while preserving the successive subcomponent hierarchies.

Pioneer-soft argues that, in the OOP-style development, we are building many basic devices (i.e. Objects) and placing all of them on a large board (e.g. FIG#1) to build computer. Every one must agree that, it is better to build the computer by partitioning the one large board, into many “loosely coupled” physical-parts (e.g. FIG#3), one for Graphics-card, one for Hard-drive and another for network-card etc.

Is it hard to believe, the plug-n-play physically-encapsulated parts can cut 70% of total costs? The costs include long-term maintenance. Since updates take less time, less risky, making applications easily adoptable and help increase user productivity.

Many Objects are used to build each “loosely coupled” part. Hence the “loosely coupled” parts are higher-level abstraction. Also it is possible to design each “loosely coupled” part to have simple high-level service-interfaces and need minimal coupling code to include into the application. Although the “loosely coupled” parts already exist, unfortunately cannot be leveraged in building the OOP applications.

Today network-card can be replaced in minutes, instead of going through risky, uncertain and error-prone process for identifying each basic device (i.e. Objects) of the network-card and removing it. If all the devices (i.e. Objects) for each part cannot be encapsulated in a replaceable-container, they likely be scattered at many places on the large main-board. Hence, to remove the part, one must remove each of its devices and resolve all dependencies (e.g. of each device has with other devices, each of which may be used as a subcomponent for other parts such as Graphics-card or Hard-drive).

Is it possible for the computer-makers to avoid crisis, similar to the software-crisis that the software makers are facing, if they also can't build hierarchies of swappable modules (i.e. assemble small devices to build larger and larger Loosely coupled parts)?

Please assume, certain constraints preventing computer-makers from assembling basic devices to build plug-n-play parts (e.g. Hard-drive or Network-card). If a system has only two components, the constraints will force him to place all the devices for the both parts on same board (i.e. merge the devices for both parts and spread them flatly on the board as shown in Figure#1-- Assuming Objects represent electronic-devices).

Please remember, he is not doing by choice, but being forced to merge all the devices and scatter on the same board. Such constraints also will prevent him from grouping the devices for each part into a separate section of the board. If he can put on separate sections, then nothing prevents him from cutting the board into 2-pieces and connect using a plug-with-pins and a socket (pins shown in Fig#2 in red). If a system has only two parts, this device-scattering is not a big problem. But, the complexity grows exponentially as he adds devices for larger and larger component-hierarchies.

For example, if he needs to add a large new part (e.g. Hard-drive), he will be forced to add many devices (for it and its subcomponents). Since he cannot physically group the devices for the new part, he will be forced to place at least 1 or 2 device at different location on the board. Hence, in effect he scattered the devices for each part (e.g. DVD-player or Hard-drive) among thousands of devices (belong to the other parts).

Then how can he replace a large part, such as, Hard-drive? Can you see the striking similarity to the problem the software developers are facing? The developers can't encapsulate the Objects (i.e. devices for the ‘loosely-coupled’ software parts) in a "swappable module" either. This forcing them to scatter at least one or two Object (i.e. device) for each part among thousands of Objects (devices for other software parts).

Furthermore, the software components have no interface standards. So, it is kind of like each device is designed for different frequencies and voltages (e.g. 3V, 5V, 7V or 9V). To understand the true complexity, we must consider the  basic components for the computers, where many of them are tightly coupled parts (i.e. silicon, plastic etc.) and not loosely coupled parts (e.g. devices).

Preserving physical representation of the design-intent in the code-implementation

The software designers (or human beings) often think in terms of ‘loosely coupled’ components. They design the products in terms of components and their loosely coupled services. Unfortunately, OOP is not able to preserve the intent by encapsulating the Objects to maintain physical separation of each component in the code. Hence the code failed to mirror/reflect design-intent. Isn't the intent 'scattered' in the implementation?

Physical structure of the code must reflect the design-intent. We must be able to physically preserve the design intent in the implementation. Also we must be able to maintain both of them in-sink all the time, during the maintenance cycles. The product-makers successfully accomplished that by employing 'component-hierarchies'. Each part and its interfaces represent design-intent. (e.g. engine, Hard-drive or CD-player).

Dr. Brooks, seminal paper ‘No Silver Bullet’ is causing more harm today unfortunately. Most people quote that, and refuse to see the contrary evidence. Just because, it re-enforces one's perception, doesn’t necessarily mean it is fact.

One time in the history, I am sure a theory that said earth is flat was popular. It was blasphemy to say earth is round. It is uphill battle to fight against such unsubstantiated false-perceptions, prejudice and arrogance of some so called experts.

Most argument in the 'No Silver Bullet' just uses perception as an evidence and not based on facts. One could make the similar argument, if computer-makers were also not able to build component-hierarchies by assembling easily-replaceable components.

Remember perception is not necessarily fact. We challenge any one to find a flaw in our logic (supported by useful examples and facts) and processes. It is absurd to say the component assembling only works for hardware and doesn't work for software.

Please click here for a proof that there is a "Silver Bullet"

All the needed pieces to build online GUI applications are available today and demonstrated in this website. So any one can start using them and validate the process. Once researchers gain sufficient knowledge and learned what is needed, we can improve programming languages for Component Oriented process for other domains such as embedded programming.