"I will work harder"-a horse named Boxer (from George Orwell's "Animal Farm")
Peter Senge's system-thinking law, mentioned in his 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 will be very happy when we solve the problem. We often do not consider the consequences. It is surprising that the solutions we have proposed can be counterproductive and pose new problems.
- As a reward for a team that has achieved great success, the company has decided to award bonuses and promote positions to a few of the team's key members. Other members of the team will feel unfair and will lose motivation. Ultimately, the relationship between team members becomes more intense, and subsequent projects can be difficult to succeed.
- The project manager frequently asks the developer to fix a new software bug, or to handle the customer's emergency needs, and the developer tries to meet these requirements. However, too frequent distraction can prevent them from completing the main tasks in the iteration. As a result, the project is progressing slowly.
2. The greater the force, the greater the reaction of the system (the harder you push, the harder the system pushes back)
When things don't work out the way we want them to, we stubbornly stick to our approach. We don't have time to stop thinking and find a better alternative, but to push forward "without hesitation." Sometimes, although the problem is solved, it is often found to be mired in other problems.
- When a system is far from complete, managers often keep urging employees to work overtime and to finish on time. The continuous increase in the number of system bugs and the sharp decline in overall quality led to more delays. Therefore, more work needs to be done to deploy the software system.
- In order to meet the requirements of the new system, the developers bravely extended the original system architecture, but the inflexible old method has not satisfied these new requirements. They are busy doing it, so that they have no time to stop to carefully analyze and change the method, resulting in system quality degradation.
3. The Curse of Fortune (Behavior grows better before it grows worse)
Short-term solutions will give us a short break and a temporary improvement in condition, but will not fundamentally solve the problem. These problems will eventually make things worse.
- Companies to provide customers with generous concessions and invest heavily in publicity, so that many people buy software. However, the customer is not satisfied with the purchase, because the software is not available and unreliable.
- If the development team is able to complete the system development on time, the management promises that the company will provide huge bonuses if the development teams can complete the system development on time. A team began to work hard, but soon they realized that it was impossible to achieve. So developers become pessimistic and lose momentum.
4. The easiest way to go out often leads to a return (the easy ways out usually leads back in)
Some of the solutions that have been learned in life can help us to succeed easily and earlier. We always try to impose them on any situation, ignoring special backgrounds and the people involved.
- When developers are not ready to accept the practice of pairing programming or test-driven development, agile coaches are forced to achieve complete extreme programming. This can bring pressure, conflict, and negative impact to any agile approach.
- It is futile for developers to apply design patterns anywhere, and this complicates the system.
5. Treatment may result in more severe consequences than 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 stress of unrealistic deadlines.
- Because of distrust of 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, its own developers do not understand, and can not make changes. Therefore, the company employees also do not understand the relevant areas of knowledge, interpretation and concepts.
- Developers will take shortcuts, copy similar code to catch up, and try to release the first version as soon as possible. They start fast, but the code eventually turns into a big mud ball (the metaphor system is not clearly structured).
6. Haste to waste (Faster is slower)
When we see the dawn of success, we will do our best and not be cautious. However, the optimal rate of growth is usually much slower than the fastest possible growth rate.
- Managers tend to add a lot of staff to successful projects, but overall progress slows because of the increased cost of communication and the loss of rapport between team members.
- Without proper refactoring and improvement of the code, developers can quickly add new features to the system, making the system difficult to understand and difficult to modify.
7. In time and space, cause and effect is not closely related (cause and effect is not closely related in times and space)
We are good at finding reasons for the difficulties that arise, even if these reasons are far-fetched and beyond the true root cause.
- In order to complete the system on time, the development team no longer accepts changes in demand from customers. Therefore, the customer is not satisfied with the software released.
- After a real-time system has been bumpy, management forces developers to agree and write detailed technical instructions before making any changes to the system. As a result, the developer loses the power to make any improvements to the system and begins to procrastinate.
8. Small changes can have a noticeable effect, but the most important place for this lever effect is often the least obvious (Small changes can produce big results-but the areas of highest leverage are often th e least obvious)
Obvious and significant solutions like changing corporate policies, visions, or advertising are often ineffective. On the contrary, small and ordinary, but continuous change will bring a very different effect.
- The developer communicates with the customer every day and makes most decisions. Therefore, to better understand the needs of customers, make better decisions and give the best solution.
- Developers design automated unit tests for each function of the system. As a result, the design is more flexible, people are more confident, and the system can be fully tested after each modification.
9. Fish and Paws can be combined, but not both (you can have your cake and eat it too–but not at once)
We often meet with a rigid "or" choice. If we change our views and our system rules, these choices sometimes do not put us in a dilemma.
- Experienced project managers know that increasing the number of system features and cutting time and expenses is not a good idea. However, this is possible if we refine our ideas, find the right people and avoid over-exploitation.
- Developers think they should either adopt a transactional script or adopt a domain model architecture pattern. However, high-performance solutions in a composite domain can combine the two to get the best performance.
10. Divide an elephant in half and never get two elephants (dividing an elephant in half does not produce, small elephants)
Inability to understand the system as a whole often makes suboptimal decisions.
- Project managers often evaluate developers by generating the amount of code and the number of functions implemented during the iteration. And developers tend to generate a lot of useless code.
- The management promised that the testers would get $5 each when they found a bug in the system. Testers are no longer interested in collaborating with developers and are no longer trying to eliminate the underlying factors that create bugs. Good and efficient relationships between teams no longer exist.
11. Beyond reproach (there is no blame)
We like to be blamed on objective conditions, or pointing at others, or even believing in it. However, both ourselves and the cause of the problem are part of the system.
- The team didn't release the system this morning. It was all Joe's fault. Even if the project manager lovingly provided him with free beer, T-shirts and pizzas, he was not able to fix all the defects in one night's time.
- People will not use a company's excellent web 2.0 social apps, users like simple and practical things, and will not appreciate the results of your hard work.
And then what?
The above 11 systems of thought laws suggest that all of the solutions we propose will have some consequences, sometimes very serious and unexpected. The systems around us are like that, and we should not criticize them, but learn from them. To master the system of thinking and control these systems, we need to do the following points:
- 1. Understand what kind of system we are dealing with, whether it is human or software;
- 2. Consciously learn the relationship, causal chain;
- 3. View the system as a whole and as part of other systems.
There are many challenges in system thinking, and we can overcome many of them by acquiring and leveraging knowledge of how systems work. But most of the serious challenges are the nature of our human conflict. Our passions, feelings, and instincts can easily change our rational, structured thinking. The first step in mastering the system mindset is to learn how to work with yourself.
The 11 system thinking laws in software development
