Peter Senge in his book "The Fifth Discipline" is mentioned in the laws of systems thinking also applies to software development.
1. Today's problems from yesterday's solutions (Today's problems come from yesterday's solutions)
When solving problems, we will feel very happy. We often do not consider the consequences. Surprising that the proposed solutions may be counterproductive, and bring new problems.
Great success as a team award, the company decided to team members of a small number of key positions bonuses and promotions. Other members of the team will feel unfair, and will lose enthusiasm. Ultimately the relationship between team members more tense, very difficult to follow-up project will be successful.
Project manager often requires developers to fix a new software Bug, or deal with the urgent needs of our customers, and developers try to meet these requirements. However, too often distracted by the iterative process would prevent the completion of their main tasks. Therefore, the project proceeded very slowly.
2. The greater the force, the greater the reaction system (The harder you push, the harder the system pushes back)
When things are going the results are not as we wish, we will stubbornly stick to their methods. We do not have time to stop thinking and find a better alternative, but "not hesitate" to press ahead. Although sometimes solve the problem, but often also found in deep among other issues.
When a system is far from complete, the manager usually will continue to urge staff to work overtime, and require time to complete. System, increasing the number of bug and the overall quality of the sharp decline, leading 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, developers of the brave to extend the original architecture, but the rigid old ways can not meet these new demands. They are busy doing it, so there is no time to stop and change the method of careful analysis, which lead to system quality.
3. Fu Xi misfortune underlies (Behavior grows better before it grows worse)
Short-term solution, will give us a short rest and a temporary improvement of the situation, but will not fundamentally solve the problem. These problems ultimately make the situation worse.
Companies to provide substantial benefits for customers and invested heavily in publicity, so many people buy software. However, the customer is not satisfied after the purchase, because the software can not be used is not reliable.
If the development team to complete the system development time, management commitment, if the development team to complete the system development time, the company will offer huge bonuses. Began to work as a team, but soon they realized that this was impossible. So developers to become pessimistic and lose power.
4. The most likely way out often leads back to (The easy way out usually leads back in)
Learned in life, some solutions will help us easily and earlier to be successful. We always try to impose any conditions on them, while ignoring the special background and related personnel.
Developers are not ready to accept the pair programming or test-driven development that practice, Agile coach, the limits of force to achieve full programming. This will give any pressure on agile methods, conflict and negative impacts.
Developers to design patterns applied to any place, it is futile, and this makes the system complicated.
5. The consequences of treatment may lead to more serious consequences than the disease (The cure can be worse than the disease)
Some well-known methods may be more dangerous, such as programming time to drink beer, to reduce the unrealistic mandate to bring pressure.
Full-time because they do not trust the developer, a company hired a large number of contractors to develop the core functionality. Result, the system does not have the concept of integrity, his company's developers do not understand and can not make changes. Therefore, employees do not understand the relevant fields of knowledge, interpretation, and concepts.
Developers will take the short cut, copy, similar to the function code to finish the work, and for the first version released as soon as possible. They began the rapid progress, but the code will eventually become a big ball of mud (metaphor system structure is not clear).
6. Haste, less speed (Faster is slower)
When we see the dawn of success, we will go all out, no longer care. However, the optimal growth rate is usually the fastest possible growth rate than the much slower.
Managers tend to increase as the project has been successful a lot of manpower, but overall progress will be slow, because the cost used to increase communication and understanding among team members lost.
In the absence of a reasonable reconstruction of the code and improve the situation, the system developers to quickly add new features, make the system becomes difficult to understand, and difficult to modify.
7. In time and space, cause and effect are not closely related (Cause and effect are not closely related in time and space)
We are good at finding reasons for the difficulties arise, even if those reasons are far-fetched and far from the real root cause.
To complete the system on time, the team no longer accept changes in demand from customers. Therefore, customers are not satisfied on the issue of software.
After real-time systems through ups and downs, management forced the developers to agree, and before any changes made to the system write detailed technical description. The results for the system developers have lost the power to make any improvements, and start delay.
8. Small changes can produce dramatic results, but the greatest leverage is often most obvious places (Small changes can produce big results-but the areas of highest leverage are often the least obvious)
Like to change the company policy, vision or language that is clear and the relationship between advertising solutions often do not work great. In contrast, small and ordinary, but sustained changes in the effect it will bring very different.
Mover to communicate with customers every day, and make most decisions. Therefore, to better understand customer needs, make better decisions and give the optimal solution.
Developers of each feature for the system design automation unit testing. Therefore, the design is more flexible and people are more confident after this modification in each system can be fully tested.
9. Cake and eat it can have both, but not simultaneously have both (You can have your cake and eat it too - but not at once)
We often face rigid "either-or" choice. If we change my point of view and the system rules, these choices do not always make us a dilemma.
Experienced project managers know that to increase the number of system features and reduce time and expense can not have both. However, what if we improve the idea, finding the right people and avoid over-exploitation, which is likely to do so.
Developers that they should either use transaction scripts, or using the domain model architecture model. However, the complex field of high-performance solutions combine the two to get the best performance.
10. The elephant will not get two and a half two elephants (Dividing an elephant in half does not produce two small elephants)
Can not understand the system as a whole, tend to make suboptimal decisions.
Project manager, often through the amount of generated code and iterative process to achieve the function to assess the number of developers. The developers will often generate a lot of useless code.
Management commitment, each found a system bug, the test will be 5 dollars. Testers on cooperation with the developers no longer interested, and no longer attempt to eliminate the bug of the underlying factor. Team relationship between the good and no longer effective.
11. Irreproachable (There is no blame)
We like to blame the objective conditions, or pointing to others, or even believe that. However, our own and cause of the problem are part of the system.
This morning the team did not release the system is entirely Joe's fault. Even if the project manager to provide a free warm beer, T shirts and pizza, and he did not time in one night fix all the defects.
People do not use a company's outstanding Web 2.0 social applications, users prefer simple, practical things, and do not appreciate your hard work.
More than 11 laws of systems thinking that all the solutions we propose will have some consequences, sometimes very serious and unexpected. The system around us to do this, we should not blame them, but to learn from. Thinking to master the system and control these systems, we need to do the following:
1. To understand that we are dealing with what kind of system is the human or software;
2. There conscious study the relationship between the causal chain;
3. The system as a whole, and part of them as other systems.
Systems thinking, there are many challenges, through access to and use of knowledge about the system works, we can overcome one of the many challenges. However, most serious challenge is the conflict with our human nature. Our passion, emotion and instinct can easily change our mind, coherent way of thinking. The first step in control systems way of thinking is to learn how to cooperate with their own.
In the software development process, you have (or lack) of experience in the use of systems thinking?
Editor's Note: The original Andriy Solovey of 15 years in software development, done developers, software managers and system architects. Concerned about the build quality, reliable and available software