Two core issues of Enterprise custom software development

Enterprise custom software development is not a computer science, and it is not a compilation principle or a combination of mathematics. So what are the core issues of Enterprise custom software development?

 

More and more people feel that they do not need to have a deep understanding of a field, but at least they need to know what the core issue is to solve when doing things in this field. For example, developing C/S structure software, State synchronization (C/S state synchronization and State synchronization between windows) is one of the core issues, and developing B/S structure software, status synchronization is not the core issue. If we know in advance that we need to consider these core issues, we can take the level of problem solving to a more macro level when we respond to the specific tasks that follow.

 

At present, I personally feel that there are two core issues for enterprise custom software development:

1. How to ensure the communication strength of all participants (development teams including customers and end users) so that they can meet the needs for achieving development goals

2. How to manage the inherent high complexity of software brought about by enterprise customization, so that the complexity does not exceed the maintenance capability of the team

 

In the previous article about the organization's blog, I talked about the first core issue, the communication intensity. In terms of the team, the most important thing for individual abilities is communication between people. Without good communication, even if the individual abilities of the team are super powerful, they cannot form a joint force. But as long as there is good communication, at least we can make the best use of it. Assume that the productivity of a standard person is 1/day. Some particularly strong people can reach 3/day. However, if the project can be completed within the time allowed by the market only when the Productivity reaches 10/day, one person cannot complete the tasks, so there is a need for the team to exist. However, there are two standards that do not achieve 1 + 1 = 2/day productivity. Only 1.5. There are three standard people, even less than 1 + 1 + 1 = 3/day productivity, it is likely to have 1.8. So what restricts the overall productivity of the team is communication. When two associated tasks A and B are performed by one person, the knowledge about task a exists in the left brain, and the knowledge about Task B exists in the right brain. The efficiency of the communication that combines the knowledge of the two tasks is the speed of the electrical signals in the brain. However, if task a is completed by Dev a and Task B is completed by Dev B, the efficiency of integrating the two tasks is limited by the vibration frequency of the human mouth, restricted by expressive ability and comprehension ability. Someone has studied that even if two people face to face, the bit rate of transmission is lower than that of the first dial-up modem. Not to mention, sometimes the development team is distributed. In this case, you cannot see your facial expressions, your body language, or share a whiteboard. You can only hear your voice on a phone call, and one of them is not working time, 1 + 1 is almost hard to achieve 1/day productivity. What is an efficient team is a team with the maximum value of 1 + 1. How to make communication more efficient. How can we make communication highly efficient? This is our core issue.

 

The first problem can be applied to the team actions of all people. As long as people gather in groups, there will be communication problems. In the so-called sense, there are rivers and lakes in some places. The second problem is specific to enterprise custom software development. For interconnected application development, the management of complexity is perhaps the second, and the most important concern is the scalability of a large number of users. However, for enterprise custom software development, the complexity of customized software is caused by the complexity of the business itself. Especially the combination of business, resulting in the complexity of the combination. Assume that, ideally, a system can be divided into modules A, B, and C, and the complexity is both 2. When complexity management is good, these modules are clearly divided. To understand a, you only need to pay attention to a and a, and a small amount of interaction between B and C with, the complexity is only 2 + 0.5 .. However, when the complexity is not managed, all the "logic" (that is, the complexity) are randomly placed. That is, there is no way to ensure that the logic of reading a only needs to focus on a, and even this A does not exist. The knowledge you see is a system that contains the functions of A, B, and C, is a complete piece. To really understand this system behavior at this time, it may take 2*2*2 = 8. With the increase of modules (variables, methods, classes, packages, modules, and bundle), we need to understand things at the same time. It is very likely that complexity cannot be managed. If we need to understand a function, we needCodeRead them all. In other words, a method has been modified, so that the entire project needs to be tested again, because nothing can be trusted. How to manage complexity? This is our core issue.

 

Interestingly, these two core issues overlap. The human and role are equivalent to classes and interfaces, all of which are abstracted as points. Understand the communication between people. The complexity is also understood as the dependency between classes. Therefore, communication issues and complexity management problems are the issue of connecting these points to form an efficient graph. This figure shows a "dependency. Dependencies between people, between classes, and between packages. Another name of the dependency is coupling. We are pursuing cohesion. Coupling (coupling)/cohesion (cohesion) the magic of these two words is that people who understand it nod their heads at a Glance based on their own experience. People who do not understand are confused no matter how they explain because they have no corresponding experience. It is precisely because of its "amazing" nature that I can say these two words are the answer to all questions (and you cannot refute them ). But at least we can know that the core issue of customized software development is: managing the dependency between good people and between packages, this allows information to be quickly transmitted between highly dependent persons (emphasizing the efficiency of message transmission caused by coupling ), understanding can be confined to a highly cohesive module (emphasizing the maintenance convenience brought by cohesion), but at the same time, it cannot make someone over-reliant on Inversion work, the more dependent, the better the physical fitness is. The same is true for package cohesion. High Cohesion is the smallest compilation unit (class ?), In addition, the packet granularity is too small, making the number of packages huge and losing the convenience of maintenance. What we need to do is to make a trade-off Based on the scenario in to depend or not to depend.

 

In terms of abstraction, both the communication problem and the complexity problem can be summarized:

1. Set the Target Indicator

2. Measure existing indicators and observe existing dependency graphs.

3. Make a dependency graph adjustment plan and execute

4. Observe the changes of indicators

5. Repeat Step 3 and 4 until the target is reached.

 

But the problem is:

1. How to measure indicators? Communication efficiency? Code quality? Are very measurable.

2. How to observe the existing dependency graph? The dependencies of packages can also be observed, but it is difficult to observe team collaboration.

3. How to adjust the dependency graph? Refactoring? Change agent? People are not as easy to change as code.

4. If the indicator is not a simple number, how can we compare it? How do you know that the indicator changes toward the target?

 

These four problems have almost no hard scientific problems. The complexity of managing complex systems may be a hard science. However, enterprise-defined software development with human factors is certainly not a hard science. Then, mathematical formulas are not the answer to these questions. In which direction should we work?

 

To be continued