Software development has reached to a dead end, and failed to adapt to market need

Software development has been struggling for years: on one hand, software projects have been suffering from high failure rate and high cost; on the other hand, all promising new trends like aspect-oriented programming, model driven development, service oriented development, etc., turned out to fail to meet their high expectations and contributed little to the advancement of software development. It seems that current software development is not going anywhere and fundamental change in software may be needed.

One of the important market forces behind software failures and high cost is change. Software development has to deal with more and more changes of requirements and environment. Unfortunately current software development methodologies failed to adapt to this need. Object-oriented programming (OOP) as the mainstream paradigm is the one to blame since it’s fundamentally incapable of dealing with change efficiently as described in the following section.

Object-oriented programming is not for change

Dealing with change has been a challenge for OOP since its start although in many cases not directly. Most of design patterns have a theme of handling varying aspect case by case. One of problems frameworks face is configuration and customization. Agile development focuses on processes that embrace change.

The effort to deal with change in these solutions can not go far since they don’t have support from programming paradigm level. For example, it’s hard for developers to learn hundreds of design patterns. In fact current mainstream programming paradigm, OOP, is incapable of dealing with change efficiently because of its fundamental weaknesses as we describe in the following. We discuss from the perspectives of cost, quality, feasibility, and scalability for change.

• Object-oriented program is not cost efficient for change
  With development cycle shorter and greater pressure of change, program source becomes more important than ever since it’s difficult to keep well-thought-out design. Program source is a way of measuring the cost of software. Not just the size of program, but both the size and the change frequencies of different areas of code are related to software cost. An area of code that changes 10 times should be considered differently than area of code that changes 1 times during program lifetime. Any effort reducing software cost ignoring change frequencies could not achieve a good result since biggest chance of reducing cost is missed. This is true for OOP since no concepts in OOP differentiate these two areas because of the OOP principle of treating everything as an object.
  
  
• Object-oriented program tends to be bloated due to stability-flexibility dilemma
  To deal with change, software need be stable enough to not collapse on its own weight, and also be flexible enough to accommodate frequent changes. These two are related to language characteristics that are often contradictory. When choosing languages, trade-off must be made and we can not maximize both at the same time since maximizing the two is like balancing a seesaw. To overcome this weakness, object-oriented programs have to throw additional objects into programs, and this often results in bloated software since adding objects is much easier than deleing objects later.
  
  
• Object-oriented program can not provide bottom up solutions for change
  A bottom up solution for change has tremendous cost advantage over case by case solution like design patterns, just like object composed of both data and functions gives OOP advantages over procedural programming. Unfortunately, class as a program unit in many object-oriented programming languages is never designed for such purpose as dealing with change. We can see that the dependency code of a class on some component often spread into different places of the class, which adds difficulty to change dependency in response to change in depended component. This creates difficulty for OOP to handle change bottom-up.
  
  
• Object-oriented program is not scalable for change
  To be scalable for change means that the cost of change on a program with multiple components, like 20 components, should not be significantly greater than the multiple times, like 20 times, of the cost of change on program with one component. This is usually not true for object-oriented programs since components of a program are logically related, and the relations can grow much faster than components, even uncontrollable, and often result in unexpected cost of change. To be scalable for change, the relations and interactions between components should be well managed. Unfortunately there are no such relation and interaction management in OOP.
  
  

Architide is committed to bring fundamental change to software

As a result of above analysis, any solution to deal with change efficiently based on OOP is impossible to reach wide range success. This is where and why Architide, Inc. is started. Architide is committed to bring the fundamental change software development needs through its vision and product.