原因在於，簡短的程式碼單元容易理解、測試及重複利用。其中程式碼單元是可以獨立維護及執行的最小程式碼集合，在C#中也就是方法(method)。
之所以會有冗長的method，除了邏輯複雜外，還可能是把太多邏輯寫在一個method中。這樣可能會導致的問題是，method不容易重複利用，因為該method集合太多邏輯於處理某一特定的功能。同時，冗長的程式碼也因為邏輯太多，導致不容易測試。
動機
簡短程式碼單元容易測試、分析和重複使用。
如何遵守此指導方針
這本書中，指導方針是一種指引，而不是一種限制。可以盡量的符合該指導方針，但不可能完全遵守。因為到最後會發現，即使遵守了一個指導方針，但可能會因此違背其他指導方針。這是因為，軟體品質有許多面向，我們不可能滿足每一個面向。我們只能在其中做取捨，找出最適合自己或環境需求的集合。
程式碼單元的長度應該限制在15行以內這個指導方針很直覺，但不見得簡單。這表示在寫到第15行程式碼之前，就必須開始思考，接下來要寫的程式碼，是真的屬於這個method嗎?還是應該擁有自己的method?或是原來的程式碼需要使用重構的技巧，提取為另一個method嗎?
如果需要透過重構把程式碼由原先的method抽取出來，書中提到了兩個重構的方式：Extract Method以及Replace Method with Method Object。都是重構中很基本卻很常用的方式，可以參考搞笑談軟工的文章：用Extract Method移除Comments怪味道 與 用Replace Method With Method Object移除Long Method怪味道。
一個很重要的觀念是，請給拆分出來的method一個清晰明白好名稱。不要取這種：DoSomethingOne()、DoSomethingTwo()、Func1()、Func2()。
常見的反對意見
在實務上，這個指導方針簡單卻很難完全做到，通常會有以下的原因及反對意見：
拆成多個method不利於效能
「撰寫簡短程式碼單元意味著會有更多個程式碼單元，因而產生更多個方法調用，衝擊效能」
理論上，多個method在.NET Run Time上的確會產生較多的呼叫程序。不過，這些是微秒等級的差別。同時，C#編譯器非常善於最佳化大量的方法調用 ，所以對效能的衝擊應該不大。為了幾微秒的效能而犧牲可維護性，其實是不智的。
程式碼分散四處難以閱讀
「程式碼被拆解成多個單元之後，變得更難閱讀。」
相對於義大利麵程式碼的寫法，程式碼分布的範圍的確比較廣。不過，有Visual Studio的幫助，這其實不太算是甚麼問題。
這個程式碼單元無法再拆分
「我的method真的無法再拆分。」
有時候真的會出現這種狀況，那就不要拆了。重點是要規則的紀律，而不是不分青紅皂白的全部依據死規則而行。
拆分程式碼單元沒有明顯的好處
「將程式碼放進DoSomethingOne、DoSomethingTwo、DoSomethingThree等方法並不能帶來甚麼好處，還不如將所有程式碼都放進一個長長的DoSomething方法中。」
事實上如果方法名稱取DoSomethingOne、DoSomethingTwo，的確沒甚麼好處，但選擇更好的方法名稱用來描述功能，那才能夠帶來一些好處。