[FW] 11 system thinking laws in software development

"I will work harder"-a horse named boxer (from George Orwell's Animal Farm)

The law of system thinking mentioned in Peter Shengji's Book Fifth practice also applies to software development.

1. Today's problem stems from yesterday's Solution(Today's problems come from yesterday's solutions)

We are very happy to solve the problem. We often ignore the consequences. Surprisingly, the solution we proposed may be counterproductive and bring about new problems.

As a reward for a team that has achieved great success, the company decided to reward a few key members of the team and promote them to their positions. Other members in the team will feel unfair and will lose enthusiasm. In the end, the relationship between team members becomes more tense, and subsequent projects are difficult to succeed.

The Project Manager frequently asks developers to fix a new software bug or handle customers' urgent needs, and developers try their best to meet these requirements. However, too frequent decentralization may prevent them from completing the main tasks in the iteration process. As a result, the project progress is very slow.

2. the more powerful the system is, the more powerful the system is.(The harder you push, the harder the system pushes back)

When the progress is not as expected, we will stick to our methods. We don't have time to stop thinking and look for better alternatives, but to rush without hesitation. Sometimes, although the problem is solved, it is often found that it is stuck in other problems.

When a system is far from complete, the manager often urges employees to work overtime and requires completion on time. The continuous increase in the number of System bugs and the sharp decline in the overall quality lead to more delays. Therefore, more work is required to deploy the software system.

To meet the requirements of the new system, developers are brave enough to expand the original system architecture, but the rigid and outdated methods can no longer meet these new requirements. They are so busy doing this that they don't have time to stop and analyze it carefully and change the method, leading to a reduction in system quality.

3. Blessings(Behavior grows better before it grows worse)

Short-term solutions will bring us a short period of rest and temporary improvement, but will not fundamentally solve the problem. These problems will eventually make the situation worse.

The company provides customers with generous discounts and invests heavily in publicity, allowing many people to buy software. However, the customer is not satisfied after the purchase, because the software cannot be used and is not reliable.

If the development team completes System Development on time, the management promises that if the development team completes System Development on time, the company will provide a huge bonus. A team started to work hard, but soon they realized that this was impossible. As a result, developers become pessimistic and lose motivation.

4. The easiest way to get out will often lead to a return(The easy way out usually leads back in)

Some solutions learned in life can help us to succeed easily and earlier. We always try to add them to any situation, ignoring the special background and related personnel.

When developers are not ready to accept the practice of Pair programming or test-driven development, agile coaches forcibly implement full eXtreme Programming. This puts pressure, conflicts, and negative effects on any agile method.

It is futile for developers to apply design patterns anywhere, and this will complicate the system.

5. The outcome of treatment may be more serious than that of disease(The cure can be worse than the disease)

Some well-known methods may be more dangerous, such as drinking beer during programming to relieve the pressure on unrealistic task periods.

Because you do not trust full-time developers, a company employs a large number of contractors to develop core functions. As a result, the system does not have conceptual integrity, so developers of the company cannot understand it and cannot make changes. Therefore, employees of the company do not understand the knowledge, explanations, and concepts in related fields.

Developers will take shortcuts to copy similar functionsCodeAnd try to release the first version as soon as possible. They made rapid progress at the beginning, but the code eventually turned into a huge ball (the system structure is not clear ).

6. Speed is not up(Faster is slower)

When we see the dawn of success, we will do our best and no longer be cautious. However, the optimal growth rate is usually much slower than the possible fastest growth rate.

Managers often add a lot of manpower to successful projects, but the overall progress slows down, because the cost of communication increases and the tacit understanding between team members is lost.

Without properly refactoring and improving the code, developers can quickly add new functions to the system, making the system hard to understand and difficult to modify.

7. In terms of time and space, the cause and effect are not closely related.(Cause and effect are not closely related in time and space)

We are good at finding the cause for the difficulties that arise, even if these are far-fetched and far from being the true root cause.

In order to complete the system on time, the development team no longer accepts changes from customers' needs. Therefore, the customer is not satisfied with the released software.

After the real-time system has experienced a bumpy journey, the management forces developers to agree and write detailed technical instructions before any modifications are made to the system. As a result, developers lose the motivation to make any improvements to the system and start to delay.

8. small changes can produce obvious results, but the biggest lever effect is often the least obvious.(Small changes can produce big results-but the areas of highest leverage are often the least obvious)

A solution that is obvious and relevant to a company's policy, vision, or advertising language often does not work. On the contrary, small and normal, but continuous changes will bring a big difference.

The sender communicates with the customer every day and makes most of the decisions. Therefore, we can better understand the customer's needs, make better decisions, and provide the best solution.

Developers design automated unit tests for each function of the system. Therefore, the design is more flexible, people are more confident, and the system can be fully tested after every modification.

9. You can have both the fish and the bear's paw, but not both.(You can have your cake and eat it too-but not at once)

We often face rigid "either-or-another" choices. If we change our views and system rules, these choices sometimes do not make us in a dilemma.

Experienced project managers know that increasing the number of system features and cutting time and spending cannot both be done. However, if we refine our ideas, find the right talent, and avoid excessive development, this is also possible.

Developers think they should either adopt transaction scripts or adopt the domain model architecture model. However, high-performance solutions in the composite domain can combine the two to achieve optimal performance.

10. Dividing an elephant into two halves won't get two elephants.(Dividing an elephant in half does not produce two small elephants)

Systems cannot be fully understood, and sub-optimal decisions are often made.

Project managers often evaluate developers by the amount of code generated and the number of functions implemented during iteration. Developers often generate a large amount of useless code.

The management promises that every time a system bug is detected, the tester will get $5. Testers are no longer interested in working with developers and are no longer trying to eliminate the root cause of bugs. Good and efficient relationships between teams no longer exist.

11. Beyond Review(There is no blame)

We like to blame objective conditions, point to others, and even trust this. However, we ourselves and the cause of the problem are part of the system.

It was Joe's fault that the team did not release the system this morning. Even if the project manager provides free beer, T-shirts, and pizza, he fails to fix all the defects within one night.

People will not use a company's excellent Web 2.0 social application. Users like simple and practical things and will not appreciate the results of your hard work.

The above 11 rules of system thinking indicate that all the solutions we propose will have certain consequences, sometimes very serious and unexpected. The systems around us are the same. We should not blame them, but learn from them. To master the system thinking mode and control these systems, we need to do the following:

1. Understand what kind of system we are dealing with, people or software;

2. Consciously learn relationships and causal chains;

3. Consider the system as a whole and as part of other systems.

There are many challenges in system thinking. We can overcome many of these challenges by acquiring and using knowledge about the way the system works. However, most of the severe challenges are the nature of conflict between us and humans. Our passion, feelings, and instincts can easily change our rational and rational way of thinking. The first step to grasp the way of thinking is to learn how to cooperate with yourself.

Remarks

What system thinking experiences do you have (or lack) in software development?

Editor's note: the original author Andriy solovey has been engaged in software development for 15 years and has worked as a developer, software manager, and System Architect. Focus on building high-quality, reliable, and available software. He wrote how to use search techniques to become an efficient programmer.

Original article: http://www.jobbole.com/entry.php/394-11 system thinking laws in software development