彼得·圣吉在其著作《第五項修煉》中提到的系統思維定律同樣適用于軟件開發。
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.
由于不信任全職開發者，一家公司雇傭了大量的承包商來開發核心功能。結果，系統不具有概念完整性，自己公
司的開發者看不懂，并且無法做出修改。所以，公司員工也不了解相關領域的知識、解釋以及概念。
