康威定律的各種解讀 - ThinkingLabs

設計系統的組織被限制生產設計，這些設計是這些組織的通訊結構的副本。
 
尤爾登和康斯坦丁更堅定地重新表述了康威定律：

組織設計的任何系統的結構都與組織的結構同構。

– Edward Yourdon 和 Larry L. Constantine，結構化設計，1979
 
埃裡克·雷蒙德 (Eric Raymond) 重申了康威定律如下：

軟體的組織和軟體團隊的組織將是一致的。

——埃裡克·雷蒙德，新駭客詞典（第 3 版），1996 年
 
COBOL 示例：

如果您有 4 個小組在開發一個編譯器，您將獲得一個 4-pass 編譯器。

——埃裡克·雷蒙德，新駭客詞典（第 3 版）p。124., 1996
 
將Tom Cheatham 的修正案新增到康威定律中。

如果一組 N 人實施 COBOL 編譯器，則將有 N-1 次透過。小組中的某個人必須是經理。

——埃裡克·雷蒙德，新駭客詞典（第 3 版）p。124., 1996
 
James Coplien 和 Neil Harrison 表示如下：

如果一個組織的各個部分（例如團隊、部門或分部）沒有密切反映產品的本質部分，或者如果組織之間的關係沒有反映產品部分之間的關​​系，那麼專案就會陷入困境……因此：確保組織與產品架構相容。

- James Coplien 和 Neil Harrison 敏捷軟體開發的組織模式，2004
 
艾倫·凱利的推論：

組織設計就是系統設計。

——艾倫·凱利，2005
 
或者由露絲·馬蘭（Ruth Malan）換一種說法：

如果系統架構和組織架構不一致，則組織架構獲勝。

– Ruth Malan，康威定律，2008 年 2 月 13 日
 
露絲·馬蘭 (Ruth Malan) 一直擅長以引人入勝的方式制定康威定律：

系統的架構以開發它的團隊的形式得到鞏固。
…

如果我們對系統分解進行初步猜測，將子系統分配給團隊，然後開始行動，康威定律也會起作用——團隊邊界將趨向於成為系統內的邊界。

– Ruth Malan，康威定律，2008 年 2 月 13 日
 
這與 Melvin Conway 在其開創性論文中提出的兩點有關：

• 一開始：“組織設計團隊的行為本身就意味著已經做出了某些設計決策，無論是明確的還是其他的。”
• 最後作為結束語：“系統的初始設計從來都不是最好的。系統可能需要更改。因此，它需要組織的靈活性來有效地設計。” 這反過來又表明了對康威推論的要求，我們將在文章的後面進一步介紹。

其他任何事情都將成為架構英雄的壯舉；當建築英雄必須與由整合時鐘的穩定節拍驅動的進度英雄競爭時，這很難實現。
架構需要跨介面發生，這也意味著跨系統/組織介面。這意味著系統架構師（我們稱其為架構師）和業務架構師（我們稱其為經理）不應該像一個對另一個沒有影響一樣工作。

– Ruth Malan，康威定律，2008 年 2 月 13 日
 
這很好地向深入討論團隊介面的團隊拓撲眨了眨眼。
關於啤酒和食物，Martin Thompson 和 Pieter Hintjes 提出了以下定義：

康威定律，粗略地指出，組織生產的東西將反映組織的溝通方式。

Martin Tompson 或 Pieter Hintjens，標題中的性別和其他故事，2013 年 12 月 16 日
 
在同一篇文章中，Pieter Hintjes 繼續……

大規模系統是跨越時間和空間的系統。一個大型組織同樣跨越時間和空間。康威定律將兩者聯絡在一起。我們的組織方式決定了我們如何集體思考，從而決定了我們集體創造了什麼。

– Pieter Hintjes, Sex in Title, and Other Stories , 2013 年 12 月 16 日
 
再次露絲·馬蘭說：

我們不僅可以期待我們建立的系統的持續進化，而且可以期待建立它們的組織形式的持續進化。
隨著我們建立更多的（自身複雜的）系統，我們可以預期組織形式必須發展以適應系統和組織中更大的系統級挑戰。
它們 [系統和組織] 將共同進化，因為如果它們不這樣做，康威定律警告我們，組織形式將勝過“跨粒度”到組織扭曲的預期設計。

– Ruth Malan，康威定律，2013 年 12 月 17 日
 
根據 Michael Nygard 的說法，系統架構是對過去企業決策的考古研究的一個很好的來源，它開啟了關於技術和政治的有趣討論：

您可以在其系統架構中閱讀企業政治鬥爭的歷史。
  
沒有最終狀態的架構意味著接受“您現在開始的更改將與去年和前一年開始的更改共存。如果你採用這種觀點，那麼你就不再試圖撕毀人行道並做一些全新的事情，你會更多地關注漸進式變化”。這裡開始了你的決策歷史。

軟體，就像所有技術一樣，本質上是政治性的。程式碼不可避免地反映了其創造者的選擇、偏見和願望

J Cascio 

政治起著巨大的作用。它扮演的很多角色都在於它的沉默。但我們不知道沉默的故事。

– Ruth Malan，Conway's Law-ish，2013 年 8 月 5 日
有趣的是，這種關於歷史和政治的討論為逐步增長或增量軟體開發如何影響組織奠定了基礎。
 
增量軟體開發是基於反饋和學習發展 IT 系統的必要條件。這是我們滿足以正確方式支援 IT 系統使用者所需的唯一方法：

零碎的增長或漸進式開發不僅是可取的，而且是軟體生活中的一個事實。即便如此，我們需要在我們的過程中建立更多的學習。當發現和解決願景（針對“正確的系統”進行路線修正）和結構（正確構建）問題的成本更低時，更多的學習。
然後，接受我們將繼續學習和發展我們的系統，我們需要投資修復錯誤。增量新增功能是的，但也要修復結構缺陷。這項投資是我們在軟體中經常忘記的關鍵的雙重到零碎增長。
當我們繼續朝著狂熱的“增值”鼓聲前進時，我們會陷入這樣一種情況：系統有可能在大量推遲的結構性問題下崩潰。
…
從我們以發現為導向的過程的混亂到我們工程系統的精心分解、經過測試的完整性，不應被視為返工或浪費！除非我們在它嚴重影響使用者和我們的業務可行性之後才離開它。那是浪費。
當我們在不確定的迷霧中前進時，熵會增加——併產生更多的迷霧！在不確定的情況下，我們“嘗試一下”；接受足夠好，然後嘗試下一件事情。隨著熵的增長，它引入了它自己的不確定性……

– Ruth Malan，康威定律混響，2014 年 5 月 5 日
 
但是增量軟體開發有一個必然的推論。隨著軟體的增長，熵也在增長。為了包含熵，我們需要重構系統。最後，許多重構導致系統的重大重新設計。增量軟體開發需要發展和重新設計組織以適應新系統。這是逆康威機動的結果。我們將在文章末尾回到這一點。與不斷髮展的系統一起發展組織:

重構是零碎增長的必然結果，允許熵控制。但我們也必須重構組織？如果它會顛覆系統（重新）設計和進化。
…
組織架構（及其通訊流程）與系統架構（及其邊界和流程）之間存在關係。我們需要考慮到這一點，以獲得協同效應，而不是做更難的事情，試圖“逆流而上”。
…
跨組織分歧進行整合是一項挑戰。當留給快樂的意外時，很可能會有意外的味道，而不是設計——就像，旨在獲得更多我們想要的東西，尋找後果，這樣我們就可以減少因系統盲目而產生的意外副作用。

– Ruth Malan，康威定律混響，2014 年 5 月 5 日
 
所有這一切都自然而然地遵循艾倫·凱利的建議：“用系統發展團隊。小團隊，小系統，零碎成長。從儘可能小的開始，並根據需要增長。不要開始想大。”
根據 Michael Feathers 的說法，當您交付產品時，您就是在交付您的組織。

康威定律——或者“你總是在組織你的組織，所以好好設計你的組織”
- @bjorn_fb，2014年4月24日
 
再次來自邁克爾：

以膠囊的形式，康威定律意味著如果你有，比如說，三個團隊，不管你是否願意，你最終都會得到三個子系統。
當溝通成本上升時，我們通常會無意識地組織我們的工作以將其最小化。
如果我更容易在我的本地團隊中分享願景和溝通，我們最終會產生一些與其他團隊的工作有點分離的凝聚力。

- Michael Feathers，推特，Reddit 和康威定律，2017 年
 
最後，我在 Dan Slimmon 的幻燈片Conway's Law: The Skeleton of DevOps 中找到了 Adam Jacob 的這個（我們假設是 Chef 的）。

您的組織結構沒有解決您的問題。
這是你以前如何解決它的神器。

– 亞當雅各布
 
這又是逆康威機動的一種表達方式。
這似乎流入了 Mel Conway 的觀察：

[康威定律] 的重要性……並不是你的設計組織決定了你可以設計的東西。
原則的重要性……是……您的設計組織阻止您設計一些您可能應該構建的東西。
該原則建立了一個必要性 (1) 不斷問：“有沒有更好的設計，因為我們的組織而無法提供給我們？” (2) 如果找到更好的設計，對改變組織持開放態度。

– Mel Conway，在多門課程中簡化應用程式開發，2016 年
 
要改變組織，你需要康威的推論：

然後就是我所說的康威推論：
“組織靈活性對有效設計很重要”。
IMO 這是他文章中最深刻的部分。
- @jeffsussna，2021年5月9日
 
沒有組織的靈活性，正如 Ruth Malan 所說，“ [當] 系統架構和組織架構不一致時，組織就會獲勝”。
組織將始終限於生產與組織的真實、實地溝通結構相匹配的設計。請注意，真正的地面通訊結構不一定是傳統組織結構圖上描述的結構。人們不會將他們的交流僅限於組織結構圖上的線條。團隊會聯絡他們所依賴的任何人來完成他們的工作。再次來自團隊拓撲的團隊介面。
這將我們優雅地帶到逆康威機動：

…組織應該發展他們的團隊和組織結構以實現所需的架構。目標是讓您的架構支援團隊完成工作的能力——從設計到部署——而不需要團隊之間的高頻寬通訊。

– Nicole Forsgren，博士，Jez Humble 和 Gene Kim，Accelerate，2018 年
 
因此，在組織團隊之前，我們需要了解需要什麼軟體架構。

團隊分配是架構的初稿。

邁克爾·尼加德， 2007
 
這意味著任何對工程團隊的組成和位置做出決策的人都會強烈影響系統架構。我們又來了露絲·馬蘭。

康威定律的另一個含義是，如果我們讓經理決定團隊，並決定將構建哪些服務，由哪些團隊決定，我們就隱含地讓經理決定系統架構。

– Ruth Malan，康威定律，2008 年 2 月 13 日
 
因此，組織設計和軟體設計是溝通的載體，兩者都需要由同一群知情人士（即經理和架構師）來處理：

最終，架構的很大一部分與技術或解決方案細節無關。這是關於建立正確的結構、工作方式、溝通渠道和整體條件
- @himal，2021 5月3日，
 
所以 …

我更相信自稱是架構師的人需要技術和社交技能，他們需要了解人並在社交框架內工作。他們還需要一個比純技術更廣泛的職權範圍——他們需要在組織結構和人事問題上有發言權，即他們也需要成為一名經理。

Allan Kelly，回到康威定律，2006 年 1 月 6 日
 
總結…

當我想到我認識的真正優秀的技術人員時……他們遲早都會意識到解決技術問題需要他們在技術領域之外工作。

艾倫·凱利，迴歸康威定律，2006
 
但 …

我在這方面有不同的經歷。理解它的領導支援我進行必要的結構性變革。不理解的領導……我很快就遇到了問題。
“你為什麼要入侵我的組織？你不是技術人員嗎？留在你的車道上”

- @himal，2021 5月3日，
 
好吧，一開始只是總結了不同人將康威定律闡明為我自己的一種筆記的各種方式，變成了思想、觀察和整個組合之間聯絡的交叉參考。這篇文章似乎成為了永無止境的作品。