Complexity of software

Currently, the architecture adopted by software is relatively difficult to solve, regardless of whether the problem to be solved is simple or complex, especially for some enterprise-level solutions.

The software is used to solve the problem. If the problem domain itself is already very complex and you use a more complex tool to solve it, the probability of success is 0. For details about the complexity of the problem domain, refer to the classic article "no silver bullet" by Brooks'. This article focuses on the complexity of software.

From the perspective of software development, complex systems usually fail, but after a failure, a relatively simple and practical system is usually derived. The initial goals of these complex systems seem perfect and can be used as a panacea. Therefore, their implementation is usually complicated, difficult to learn, and difficult to use. At this time, some relatively simple systems that achieve the same goal will emerge. Although these simple systems have some defects, they are very practical and generally more widely used than their complicated predecessors. The following examples fully illustrate this point:

UNIX, which was born to simplify multics, has been widely used for more than 30 years. It should be okay to continue using it for another 30 years. The core idea of UNIX is to keep it simple. (See Eric S. Raymond the art of Unix programming)

The TCP/IP protocol widely used on the Internet is simplified from an OSI (Open Systems Interconnection) model. In the OSI model, the network is divided into Layer 7 instead of Layer 4 of TCP/IP. It is much more difficult to implement a layer-7 protocol than a layer-4 protocol. Although there are also layer-7 implementations, due to too many bugs, it is eventually replaced by TCP/IP, which is relatively easy to implement.

Lightweight solutions for J2EE complexity, such as spring, hibernate, and Ruby on Rails.

In another example of mail, SMTP and POP3 are currently used with many design flaws, leading to security risks and spam, but compared with the complicated x.400 protocol, SMTP and POP3 are much easier to implement, and in most cases, they can meet users' needs for sending emails. So x.400 is rarely seen now.

The reasons for software complexity are roughly as follows:

• Pursuing perfection, I want to invent a silver bullet ". We hope that the system can provide a perfect and general solution for the problem to be solved. Therefore, we will add all possible situations to the system implementation, making the system complex and huge. Such as multics, CORBA, and OSI. In practice, such a system usually has no long vitality or is widely used.

 

• The process of using the system gradually becomes complex. The initial design of the system draws on the previous vehicle experience, which is relatively simple. However, as the number of users increases, new demands are constantly raised. In addition, the competition should be prioritized, and new features will be constantly added to the system, make the system complex. Java is an example. At the beginning, C ++ was simplified a lot, and it soon became popular in the software industry. But after 10 years, I will look at Java again. The simplified features have basically been added to the system. This complexity of Java makes some relatively simple dynamic languages very popular.

 

• Interest-driven or personal performance. If the system is not complicated, the price cannot be increased. In addition, the complexity of the system makes it difficult to see the depth of the system.

 

Hazards caused by software complexity:

• Increase development difficulty and reduce development efficiency. Developing a complex system requires a lot of effort to cope with the additional workload brought about by the complexity itself. It cannot effectively focus on solving the problem itself, resulting in reduced development efficiency.

 

• Increase maintenance difficulty. Maintaining a complex system is a tough task. You must always guard against faults caused by system instability. To expand the system, its complexity will become an obstacle that needs to be overcome.

 

• Increases the learning and usage difficulty. Complexity will make the learning curve steep. If the encapsulation is poor, it will cause a lot of inconvenience to the operation. It usually takes a lot of time to grasp the operation.

Hall, winner of the Turing Award and inventor of the quicksort algorithm, once said that there are two ways to develop software: one is to make the system as simple as possible so that it does not seem defective; the other is to make the system very complex, making it difficult for you to see its defects.