The System Thinking Laws from Peter Senge’s book “The Fifth Discipline” applied to Software Development.

彼得·圣吉在其著作《第五项修炼》中提到的系统思维定律同样适用于软件开发。

1.Today’s problems come from yesterday’s solutions(今天的问题源自昨天的解决方案).
We, humans, are happy when we solve problems. We often don’t think much about consequences. Surprisingly, our solutions
could strike back and create new problems.
当解决问题时，我们会感到很高兴。我们经常不考虑后果。令人感到意外的是，我们提出的解决方案可能会
产生反作用，并带来新问题。
[1]A company decides to reward few key members of the very successful team with bonuses and promotions. The rest of the
      team feel unfairness and loss of motivation. Eventually tension between members is increased. The following projects are no 
      longer successful.
    作为对取得巨大成功的团队的奖励，公司决定为团队中的少数骨干成员发放奖金并晋升职位。团队中的其
    他成员会感到不公平，并且会丧失积极性。最终使团队成员之间的关系更加紧张，后续项目也就很难再取
    得成功。
[2]A project manager frequently asks developers to fix a new bug or work on urgent requests from customers. Developers do
      their best to fulfil these requests. Frequent distractions prevent them from finishing their main tasks for the iterations. Project
      shows only little progress.
      项目经理频繁要求开发者修复一个新的软件Bug，或者处理客户的紧急需求，而开发者尽力满足这些要求。
      但是，过于频繁地分散精力会妨碍他们完成迭代过程中的主要任务。因此，项目进展很慢。
2.The harder you push, the harder the system pushes back(用力越大，系统的反作用力也越大).

We have this stubborn reaction to push our way through when things are not working out as we want. We charge without time to
stop, think and find better alternatives. Sometimes we solve problems, but often we find ourselves up to ears in the swamp of other
problems.
当事情的进展结果并非如我们所愿时，我们会固执地坚持自己的方法。我们没有时间来停下来思维并寻找更好的
替代方案，而是“义无反顾”地向前冲。有时候虽然解决了问题，但往往又发现深陷于其他问题之中。
[1]Managers keep pushing people to work overtime and meet deadline when a system is far from completion. The number of bugs is
      increasing and overall quality is rapidly dropping causing more delays. More and more effort is required to launch the software system. 
     当一个系统远未完成时，经理通常会不断催促员工加班加点地工作，并且要求按时完成。系统bug数量的持续
   增加及整体质量的急剧下降，导致更多的延误。因此，需要做更多的工作来部署软件系统。
[2]Developers heroically stretch the same architecture for the new system requirements, which don’t fit into the old rigid way. They are
      so busy doing it that don’t have time to stop, analyze and change approach. The system degrades. 
      为了满足新系统的要求，开发者勇敢的对原有的系统架构进行扩展，但死板陈旧的方法已经不能满足这些新需求。
   他们忙于做这件事，以至于没有时间停下来仔细分析并且改变方法，从而导致系统质量下降。
3.Behavior grows better before it grows worse(福兮祸之所伏).
Short-term solutions give us a short break and temporary improvement, but don’t eliminate fundamental problems. These problems will make
situation worse in the long run.
短期的解决方案，会给我们带来短暂的休息和状况的暂时改善，但是不会从根本上解决问题。这些问题终究会使情
况变得更糟。
[1]A company gives customers hefty discounts and run expensive advertisement – many people buy the software.
     Customers are unhappy after purchase, because software is unusable and unreliable. 
     公司为顾客提供丰厚的优惠并投入巨资宣传，让很多人购买软件 。但是，顾客购买之后很不满意，因为软件无法
   使用也不可靠。
[2]Management promises development team big bonuses if they finish system in time. A team work hard, but soon realize that it is impossible.
      Developers becomes cynical and unmotivated. 
     如果开发小组能够按时完成系统开发，管理层承诺，如果开发团队能够按时完成系统开发，公司会提供巨额的奖金。
   一个团队开始努力的工作，但很快他们就意识到这是不可能实现的。于是开发者变得悲观并丧失动力。
4.The easy way out usually leads back in(最容易出去的方法往往会导致返回来).
We learn few solutions in our life, which brought easy success earlier. We try to vigorously apply them in any situation disregarding particular
context and people.
在生活中学到的一些解决方案能够帮助我们轻易地并且更早的地获得成功。我们总是试图把它们强加到任何情形上，
而忽略了特殊的背景以及相关人员。
[1]Agile coach is forcing full Extreme Programming implementation when developers are not ready to accept some practices as pair programming
      or TDD. It creates stress, conflicts and allergy to any Agile approach. 
      开发者还没有准备好接受结对编程或者测试驱动开发这样的实践时，敏捷教练强行实现完全的极限编程。这会给任何
   敏捷方法带来压力、冲突以及负面影响。
[2]Developers apply design patterns everywhere unnecessarily complicating the system. 
      开发者把设计模式应用到任何地方，这是徒劳的，而且这会让系统变得复杂。
5.The cure can be worse than the disease(治疗带来的结果可能会比疾病导致后果更严重).
Some familiar solutions could be even dangerous like drinking beer while programming to reduce stress for unreal deadlines.
有些熟知的方法可能会更危险，比如在编程的时候喝啤酒，来减轻不切实际的任务期限带来的压力。
[1]A company hires various contractors to work on core features, because doesn’t trust full-time developers. As a result, the system doesn’t
      have conceptual integrity, in-house developers don’t understand and cannot change it. Domain knowledge, interpretation and concepts are
      missing from the brains of company employees. 
      由于不信任全职开发者，一家公司雇佣了大量的承包商来开发核心功能。结果，系统不具有概念完整性，自己公
   司的开发者看不懂，并且无法做出修改。所以，公司员工也不了解相关领域的知识、解释以及概念。
[2]Developers make many shortcuts, copy and paste code for similar functionality to please management and deliver first version fast. They
      do quick progress at the beginning, but code eventually becomes Big Ball of Mud. 
     开发者会走捷径，拷贝相似功能的代码来赶进度，并且争取尽快发行第一个版本。他们一开始进展迅速，但是代
   码最终会变成大泥球(比喻系统结构不清晰)。
6.Faster is slower(欲速则不达).
When we feel smell of success we start advance at the full speed without much caution. However, the optimal rate of growth usually is much
slower than the fastest growth possible.
当我们看到成功的曙光，我们会全力以赴，不再小心谨慎。然而，最优增长速率通常会比可能的最快增长速率要慢得多。
[1]Managers add many people to already successful project. The overall progress becomes slower, because of communication overhead
     and loss of team coherence. 
     经理们往往为已经成功的项目增加很多人手，但总体进展就会变慢，因为交流所用的花费增加，以及团队成员之间
  失去默契。
[2]Developers quickly add new features to the system without proper refactoring and improving existing code. System becomes difficult
      to understand and modify. 
      在没有对代码进行合理重构及改善的情况下，开发者快速的为系统添加新的功能，会使系统变得难懂，而且难以修改。
7.Cause and effect are not closely related in time and space(在时间和空间上，因果并不密切相关).
We are good at finding causes to our problems, even if they are just symptoms and far from real root causes.
我们善于为出现的困难寻找原因，即使这些原因很牵强，并且远非是真正的根本原因。
[1]Development team stops accepting requirement changes from customers to finish a system in time. Customers are unhappy with delivered
      software. 
     为了按时完成系统，开发团队不再接受来自客户的需求改变。因此，客户对发行的软件不满意。
[2]After few incidents with a live system, management compel developers to get approval and write detailed technical specification before
      implementing any change in the system. Developers lose motivation for any improvements in the system and start procrastinating. 
    实时系统历经坎坷之后，管理层迫使开发者同意，并且在给系统做出任何修改之前撰写详细的技术说明。结果开发者
   失去了为系统做出任何改进的动力，并且开始拖延。
8.Small changes can produce big results-but the areas of highest leverage are often the least obvious(微小的改变可以产生明
显的效果，但这种杠杆效应最大的地方往往也最不明显).
Most obvious grand solutions like changing company policy, vision or tag line often don’t work. Small ordinary, but consistent changes could
make a huge difference.
像改变公司政策、愿景或者广告用语这样显而易见并且关系重大的解决方案往往不起作用。相反，小而普通，但持续的改
变却会带来大不相同的效果。

[1]Developers have everyday interactions with customer and make most decisions. As a result, customer needs are well understood, decisions
are better and solutions are optimal.
开发者每天都与客户进行交流，并且做出大部分决定。因此，能够更好地理解客户的需求、做出更好的决定并且给出最优
的解决方案。

[2]Developers build automated unit tests for each function in the system. As a result, design is flexible, people are confident, the system is fully
tested after each change.
开发者为系统的每项功能设计自动化单元测试。因此，设计更灵活、人们更自信、系统在每此修改之后都能得到完全的测试。
9.You can have your cake and eat it too – but not at once(鱼与熊掌可以兼得，但不是同时兼得).
We often face rigid “either-or” choices. Sometimes they are not dilemmas if we change our perspective and rules of the system.
我们经常会面对刻板的“非此即彼”选择。如果我们改变一下自己的观点及系统规则，这些选择有时并不会使我们进退两难。
[1]Experience managers know that we cannot increase the number of features and reduce time and cost simultaneously. However, it could be
     possible to achieve if we just improve flow of ideas, find right people and avoid over-engineering. 
     经验丰富的项目经理知道增加系统特性的数量与削减时间和开支不可兼得。然而，如果我们完善一下想法、寻找合适的人
   才并且避免过度开发，这也是可能做到的。

[2]Developers believe that they should follow either Transaction Script or Domain Model architecture patterns. However high performance
     solution in the complex domain can combine both for the best effect. 
    开发者认为他们应该要么采用事务脚本，要么采用域模型体系架构模式。然而，复合域中的高性能解决方案可以将两者结合，
  以得到最佳性能。

10. Dividing an elephant in half does not produce two small elephants(把一头大象分两半不会得到两头大象).
Inability to see the system as a whole could often lead to suboptimal decisions.
无法整体了解系统，往往会做出次优决定。
[1]A manger evaluates developers based on the number of lines of codes they produce or points they implemented during iteration. Developers
     produce a lot of useless code. 
     项目经理往往通过生成的代码量和迭代过程中实现的功能数来评估开发者。而开发者往往会生成大量无用代码。
[2]Management promises testers $5 dollars for any found bug in the system. Testers are no longer interested in cooperating with developers and
     prevent root causes of the bugs. Good and productive relations between teams disappear. 
     管理层承诺，每发现一处系统bug，测试者将得到5美元。测试者对跟开发者合作不再感兴趣，并且不再试图消除产生bug
   的根本因素。团队之间良好而且高效的关系不复存在。

11. There is no blame(无可非议).
We like to blame and point fingers to other people or circumstances, sometimes we even believe in this. But we and cause of our problems are
part of the System.
我们喜欢归咎于客观条件，或对别人指指点点，甚至对此深信不疑。但是，我们自己以及问题的原因都是系统的一部分。

[1]It is Joe fault that the team didn’t release system this morning. He didn’t fix all the bugs overnight even though PM kindly gave him free pack
     of beer, T-shirt and pizza. 
    今天早上团队没有发布系统完全是乔的过错。即使项目经理亲切地为其提供了免费的啤酒、T恤以及披萨，他也没能在一
  晚上的时间内修复所有的缺陷。
[2]People don’t use a company’s excellent Web 2.0 social application. Users are simply stupid and don’t appreciate
     hard work. 
    人们不会使用一个公司优秀的Web 2.0社会化应用，用户喜欢简单实用的东西，并且不会感激你辛勤工作的成果。

So what(然后呢)?
These 11 laws of The System Thinking show that all our solutions have consequences, sometimes bad and unexpected. Systems around us are
what they are, and we shouldn’t blame, but learn them. To master The System Thinking and control these systems we should
以上11条系统思维定律表明，我们提出的所有解决方案都会产生一定的后果，有时非常严重并出乎意料。我们周围的系统本
就那样，我们不应苛责它们，而是要从中学习。要掌握系统思维方式并控制这些系统，我们需要做到如下几点：
[1]understand what are the systems we are dealing with, either human or software. 
  要明白我们是在跟什么样的系统打交道，是人或是软件；
[2]consciously learn relations, cause and effect chains 
    有意识地学习相互关系、因果链；
[3]perceive the systems as a whole and as the part of other systems 
    把系统看做一个整体，并且视其为其他系统的一部分。
There are many challenges to the system thinking. Many we can defeat with gaining and using knowledge how systems work. But the most serious
challenge is our own contradictory human nature. Our passions, emotions and instincts could easily defy the rational and systematic way of thinking.
First step to master the system thinking is to learn how to cooperate with ourselves.
系统思维方面有很多挑战，通过获取并且利用有关系统工作方式的知识，我们可以战胜其中的很多挑战。但是，大部分严峻挑
战是我们人类与之相冲突的本性。我们的激情、感情以及本能可以轻易改变我们理智、条理分明的思维方式。掌握系统思维方
式的第一步就是要学习如何跟自己合作。

Question: What is your experience with the system thinking (or absence) in software development?
在软件开发过程中，你有（或缺乏）哪些系统思维的使用经验？

From : http://softwarecreation.org/2007/11-laws-of-the-system-thinking-in-software-development/