Why Software Development is in CRISIS?

The way we design and develop the software is fundamentally flawed. Software developers spend over 80% of their time building and comprehending complex unstructured non-essential dependencies (i.e. irrational dependencies) between the Objects. The fundamental limitation of the programming languages is unable to encapsulate the components is a container and build physical component-hierarchies.

To instantiate, initialize and customize an Object to present for a component such as reusable Pie-chart-class usually require on average several tens to hundreds of lines of code.  These figures Figure#3, Figure#5 and Figure#7, only one line (e.g. an arrow) to show dependences between any two types of the Objects (i.e. Data-Objects and GUI Objects etc.). However, if we need to represent each function call we need to draw tens of lines between the objects (as explained in this example). 

For example, function calls, such as, to Get-data from one Object and Set-data to other Object. This type of Object integration tightly binds the Objects and such Object integration code constitutes 50% or more of the component code. It is hard to track and maintain such large unstructured coupling code and large number of Object dependencies, which grows nearly exponentially as the size of the application grows or number of the Objects in the application. Now you could see why most OOP applications end up as Object blender and spaghetti code maker. But CBSDF minimizes dependencies between interacting components (click here for quick pictorial over view of CBSDF).

On the other hand, the well-designed “loosely coupled” component usually supports on average two services, which can be represented by two arrows (as stated at the bottom in the example), one for each service function call. Fig#4, fig#6, Fig#8. Therefore, the CBSDF could effectively eliminate nearly 80% of the dependencies or coupling between interacting components (i.e. minimizes the rational-dependencies and almost eliminates the irrational-dependences).

It is certainly possible to minimize the coupling for the CF (i.e. Loosely coupled AC). if you study any system, an “average” component provides 2 kinds of services. Of course, some components may provide more and in general many interact with None. Please remember, shopping-cart may need to interact with many shopping items, but it provide only one kind of service, hence it needs only one line of coupling code, for example, register its service Object with Global directory of services.

The hierarchical encapsulation of subcomponents and the “unified handler” is extremely important to control the complexity and to preserve independency of each part. This allows to refine or replace with little concern on the impact on other parts in the system. I cannot under state the importance of "unified handler", especially their hierarchies. With out the ability to hierarchically subdivide them, most parts still end up complex. All the manufactured products use this hierarchical encapsulation of subcomponents and the “unified handler”. With out the super-distribution of the complexity even presumably simple manufactured product will be far more complex than complex software (as articulated by Mr. Brad Cox at the middle that pencil making is more complex than MS-Word 3.0).

For example, HardDrive encapsulates many components, and we need no knowledge of its subcomponents to remove it. How can we remove a large subsystem in a software, which contains 300 Objects spread across many files? If you were asked to replace a Graphics-card in a computer, it is a piece of cake. You just open the PC-box and un-plug the old Graphics-card and plug-in a new Graphics-card. You don’t need to worry about painstakingly chip away each Object (e.g. parts such as IC-chip or electronic device) on the Graphics card and replace with new part and resolving both the internal dependencies between parts and external dependences with other parts (or devices). The plug-in parts offer "unified handle" to remove or replace.

But, if you need to replace similar size subsystem in a large application, you need to remove most Objects (ingredients and subcomponents) used to build the subsystem. This task involves painstakingly understanding and resolving numerous irrational dependences of each Object. Imagine the complexity, if we build computers as we build software.

If the product-makers (e.g. car and computer) also cannot build component hierarchies, they would also face similar crisis, the software makers facing today. Please click here for a simple example and logical reasoning (see Figs4&5) to back this assertion.

If you take each part (e.g. graphics-card, CD-player and Hard-disk) in the computer and take apart all their subcomponents (i.e. electric devices, such as, logic-chips, memory-chips, voltage-transformers and capacitors). Remember that many subcomponents (e.g. motor in CD-Drive) contain devices as subcomponents. Blend the devices and place all of them on a large enough Circuit board. Then use wires to connect them to rebuild the computer. If you able to build functional-computer, the 'blended-devices' computer looks more like how we build the software.

(OK! One may argue you must organize the way one organizes the Objects, such as, Aspect Oriented style. For example, place all the logic chips on a board, memory chips on a separate board and capacitors on yet another separate board etc. Now connect them with wires to build computer. Does it really decreases the irrational dependencies and make it simple to replace a component, such as, the Hard Drive?).

(Hey why don't we save couple of bucks by using CD-player's motor capacitor for Hard-drive motor as well. OK, if it has different voltage rating, just use a rectifier to compensate. Cool Idea!  Lets see what other devices can be tweaked for reuse?) 

This "blended-devices" computer will be still simpler compared to the dependencies between the software Objects. Because, in the blended-devices computer, we are still dealing with plug-in electronic-devices (e.g. an IC-chip and capacitors) and not at the level of tight coupling of the chip's ingredients, such as, silicon and metal oxide. Furthermore, all the chips are likely standardized for 5 Volts-DC and don’t need to resolve voltage dependencies by designing a transformer between two chips. I can't even imagine how one could resolve parametric differences (e.g. frequencies and time or propagation-delays).

Pioneer-soft invented the missing-link software interchangeable code-blocks, which in-effect comparable to the invention of interchangeable parts that revolutionized 19th century manufacturing and led to 20th century revolutionary invention assembly-line.

Summary for the 'Component-Oriented' programming

If one wants to invent component-oriented programming, what ought to be the requirements or Objectives? That is, what the programmers must be able to do in the component-oriented programming, which they could not do before?

It is not a complex question to answer, since the world already experienced two programming paradigms: Structured programming and Object-oriented programming.

The structured programming allows developers to encapsulate related "data" in an abstraction and it can be referenced through a variable. The Object oriented programming allows developers to encapsulate related "data" and "methods" in an abstraction and it can be referenced through a variable. Each of the abstraction allows the programmers to build arrays and hierarchies of Structs or Objects respectively.

Likewise, the "Component-oriented" programming must allow encapsulation of related "data" & "code" for a component in an abstraction, must allow referring through a variable. One must be able to use the variables to build Arrays & Component-hierarchies.

Is there any advantages for the "Component-oriented" programming?

The product-manufacturing (e.g. computers & cars) processes are absolutely component-oriented and reaping huge benefits. If they were not component-oriented (i.e. no component-hierarchy), they would face similar crisis, the software-makers are facing. 

For example: The computer-makers end up building the "blended-devices" computer, if they were not able to build component-hierarchy (e.g. assemble devices to build each plug-n-play part). Each of the parts (e.g. Network-card or Hard-drive) will be there. However each part is not encapsulated in a single plug-n-play package. Instead dozens of devices belong to each part will be spread across the large Circuit-board.

The code in today’s applications contains large portion of unstructured randomly spread object-interaction code that creates  irrational dependencies between the Objects. It is not practical to document, track or index Object dependencies, which constitutes large portion of the code. Hence, nearly impossible to rationalize or contain the complexity with in each subsystem (for example to remove or refiner the subsystem independently). It is nearly impossible to predict what sort of effect a simple change might have on other parts in such tightly coupled application. This is the source for numerous known problems. Couple of them listed below:

1.

Software today is a technology in crisis, where its complexity has far outrun our ability to comprehend it. It’s next to impossible to understand what is going on in software whenever a program runs longer than a few hundred lines of code—and today’s software applications contains millions of lines. What we don’t understand, we can’t fix or maintain (e.g. adapt to evolving need): 25 percent of commercial software projects are canceled, which meant $60 billion in losses in year 2000 to the U.S. economy alone.

2.

Software bugs, or errors, are so prevalent and so detrimental that they cost the U.S. economy an estimated $59.5 billion annually, or about 0.6 percent of the gross domestic product, according to a study commissioned by the Department of Commerce. The main source for the bugs is the complexity of the software. The complexity is obviously resulting from this un-encapsulated spaghetti-code or unstructured hard to rationalize artificial dependencies between the Objects.

Savings of few billion here and there could add up to real huge savings. Investing in the research and development to build Tools and improved processes for the “Loosely Coupled” systems could result in huge savings to the world economy. Furthermore, additional benefits such as listed below could result in substantial productivity gains, hence improved standard of living to the world economy:

1.

The “loosely coupled” paradigm would allow us to build many times more complex systems than possible before, which could solve complex problems, for example, to advance our knowledge or to overcome outstanding issues.

2.

The plummeting cost of application development and ability to quickly adapt to the evolving needs would make them far more pervasive and useful. The cheap access to the information at fingertips would improve the productivity of the world economy, for example, by streamlining the business processes or by removing the inefficiencies in the supply chain.

3.

The “loosely coupled” paradigm offers a new dimension of freedom and flexibility, which opens up vast uncharted territory and creative possibilities to invent new kind of software, we haven’t thought of yet.