“Dreaming in code”: Software is hard

最近有本很有趣的新書出來，叫做 “Dreaming in code”。

它的要義很簡單：

… is basically an attempt to answer the question: “Why is writing software so hard?”

這本書主要有趣的地方在於

1、它是作者 Scott Rosenberg 透過田野調查的方式追蹤一個真實世界的軟體專案四年後所得的結論

2、這個軟體專案是由一群精英 developer 所組成的團隊來開發，但四年過去仍然無法結案，光看這個 case study 就值回票價

＊背景資料

作者追蹤的project 叫做 Chandler，是由 Open Source Applications Foundation(OSAF) 基金會出資五百萬美元開發的一套 PIM(個人資訊管理系統，簡單說就是把日曆、通訊錄、to-do list 甚至 email 大雜燴一番，講的更白一點，就是開源版的 Outlook)

Chandler 使用 python(主要程式語言) 與 wxWidget(UI介面與元件) 寫成，開發團隊則是由業界一群精英中的精英工程師所組成，這裏面有些人當年寫出第一版的 Netscape navigator，有的人曾負責寫早期 mac os 的kernel，但專案開始四年後，卻仍然面臨進度嚴重落後，甚至連公開 release 版本都難產的下場。

在網路上可看到的兩篇 sample文章裏，Scott 用非常淺顯的方式介紹了 Chandler team 為何會遭遇這樣的困境，文中的例子是 bug no. 44: flicker-free window resizing。

這個例子主要的精華是說開發團隊發現app在 resize後，所有的元件都會閃動(flicker，不是那個相簿網站)一秒鐘，原先工程師以為這是小bug，只要四小時即可解決，但結果是八個月後這個bug no. 44 還是在 bugzilla 中沒被修正。

事後檢討為何會拖這麼久都沒法度？這才得知工程師在仔細追蹤後發現這個bug是來自所使用的 wxWidget 元件組有問題，但這部份他們沒法自已改，只能等 wxWidget 的人修正，或想辦法用其它方式解決，但光是為了確認這個 cause，就花了數倍於四小時的時間。

為此，工程師們還使用了諸如 dragon, snakes, scary, treasure-hunting 等名詞來形容這種如黑洞般的 bug。

看完這幾章，就已經讓人心有戚戚焉，也讓我不禁開始思考一個問題…

* 為何會這樣？

從 Chandler 的例子來看，能初步觀察到的原因大概就是

-可能與開發使用的語言有關？

我可以理解他們選擇 python 與 wxWidget 主要的原因都是為了跨平台，讓 Chandler 將來可同時在 win/mac/linux 上執行，但一個根本的問題是，這兩樣技術本身都還各有者大小不一的毛病，而且它恐怕也不是所有工程師最熟悉的語言(當年寫 netscape 或 mac os kernel 用的應該是 c系列吧？)

-軟體工程中本來就會有的 黑洞( scary, dragon, snake, treasure-hunt, uncertainty, estimate based on estimate)

當然一個 project 要成功，需要天時地利人和加祖上積德福報雄厚，而一個project 要沉船，也同樣可以有成千上萬個原因，因此或許我們可以說，Chandler 會有這種下場，本來就只是忠實呈現了所有軟體專案中都存在者的那個黑洞(不然為何一個訂票系統也會落得同樣的結局？)

只是較讓人驚訝的是，即使是一群精英所組成的團隊，也無法逃過黑洞吞嗜的命運，這聽起來就很像是即使李麥克、馬蓋先、天龍特攻隊加飛狼組成一個 task force，也沒法順利的把王又曾抓回來(我到底在講什麼？不過大概就是1+1 != 2 這樣的意思…)

-如果用 apollo 會讓這件事進行的更快、更好、更省錢嗎？

在胡思亂想完一堆Chandler 失敗的可能 causes後，另一個直接的延伸思考就是：如果今天是用 apollo 開發，結果會有任何不同嗎？

我很希望答案會是肯定的。

因為就技術層面來說，flex/mxml/actionscript 是相對簡單的東西(至少跟 C++比是這樣)，而它們最大的優勢之一就是天生跨平台，學習曲線較低，avm 執行效能可能也比 python 快一點。

但實務面來說，我認為專案該面臨的『黑洞』仍然會一個不少，屬於apollo 的 bug no. 44 只會以不同的面貌出現，終究得靠工人智慧去解決。

所以當把兩種角度結合起來想這件事時，就會發現很難給出一個確定的答案，因為實在太難了(now you know why software is hard !)

這就像是，如果今天用 apollo/flex 去寫x鐵訂票系統，下場就一定會比較好嗎？我想除了介面肯定會漂亮許多之外，其它的事可很難說的準。

*書中佳句

下面擷錄幾段書中佳句

-為何開發軟體很困難？

“is simply the incredible difficulty of estimating the time it takes to do this stuff, whether you are building a little content management system for a relatively modest-size Web company or whether you are building the operating system that will be used by three-fourths of the known universe.”

-為何不要重新發明輪子？

Except that what he will write, most likely, is something that will work but will not have its rough edges worked out, will not have the benefits of a piece of software that has actually been used for a few years, where the bugs have been found and the users have given feedback and have helped you figure out where the problems are.

工程師通常都會說：我自已重寫一個比看別人的快，但別人的東西可能是 tried and true 而且通過經年使用驗証，你或許可以寫出類似/堪用的東西，但最後可能被潛在的 bug 淹死。

這裏的重點是：自尊心是一回事，確定事情有做好是另一回事。

-作者最後特別強調一次本書的目地

right off the bat that I needed to be really clear with people that I wasn’t writing a how-to book, and I wasn’t writing a book of advice.

意思是：這本書不是十全大補丸可以六分鐘護一生，也不是那種 teach yourself 系列 step by step 的指導手則，它不會教你什麼實際的方式去避免專案失敗(看一下「人月神話」可能效果好一點)

但我的想法是：知道別人怎麼死的，拿來當個借鏡也是不錯的啊。