[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.
无法整体了解系统，往往会做出次优决定。