發表文章

目前顯示的是 12月, 2006的文章

白目鄰居... 怒...

星期六晚上要參加朋友的婚禮, 因為要當招待, 下午就潔身沐浴, 穿戴整齊兩點半就打算出門... 才一出門就怔住了, 鄰居的綠Corsa正正地停在巷子口, 後面三台車全被他擋住了. 好吧, 因為巷子小, 大家又都有車, 這樣併排無可厚非, 有留電話就好. 那就打個電話去吧... 我: 拍謝, 麻煩移車好嗎? 老伯: 蝦咪? 我: 樓下移車... 老伯: 害囉... 我滴呀陽明山上吶... 我: $#%@^% @# 你媽的咧, 最好車子這樣停, 敢從基隆跑去陽明山上玩, 還不留鑰匙什麼的替代方案... 最後就花了四百塊坐計程車去台北了... 花錢事小, 後來兩天沒車過的實在很痛苦, 去擠台鐵極不準時, 上面又有怪味外勞的火車回家... :(

人月神話...

人月神話這本書已經上市超過30年了, 大多數的人總還是認為在一個軟體Project裡加人, 可以縮短需要的時間. 而事實上, 除了低技術的勞力密集工作之外, 在這個時代裡, 很少有工作可以符合這種依人數變多而時間可以縮短的期待了... Wiki有人月神話的 link Adding manpower to a late software project makes it later. 他所持的道理很簡單, 只有兩條... 加人進來, 新人是需要學習的, 在學習的時候是沒有生產力的, 且必然地會拖累老手的生產力. 所以在Project的愈後期加人, 不但沒有幫助, 反而是一種拖累... 人愈多, 所需要的溝通就愈多. 兩個人之間只有一條channel, 三個人就有三條了, 四個人就六條, n個人就n(n-1)/2條channel, 人愈多, 這中間的over head就愈高. 就我來說, 還有一個原因, 那就是做軟體並不是一個線性的生產線, 就算是一條生產線, 也不代表可以走捷徑. 一個小程式要經由ABC三個步驟來達成, 就一定得先完成A, 才能做B, 做完B, 也才能做C. 不可能說給三組人同時做A, B跟C. 最後再同時組起來, 結果就只需要1/3的時間... 就像蓋房子, 1個人蓋100天的房子, 絕不是100個人一天就可以蓋起來. 這樣的神話, 已經被點出了30年, 為什麼還沒有辦法變成資訊界的Common Sense呢?

這樣的安排, 可以被理解...

人事上又有小小的變動了, 對我來說其實變動不是太大, 因為雖然人的內容有變, 但跟原本的人數一樣. 之前說要加進來的人, 又還沒加入. 所以這個改變還好. 而要做的事情是被切的更小, 更明確了. 而這個新的安排背後的用意, 完全能夠了解...

PM的功能...

今天連三PO啊... 一直把PM這個角色想的太全能, 如果把PM跟RD的關係想成是出一本書時, 編輯跟作者的關係, 好像就比較釋懷了...

不能理解為什麼這麼多程式會有這種設計...

圖片
在很多很多程式及網頁裡, 都可以看到有選國家的地方. 像是選時區或是出生國家等等. 我不能理解的是, 為什麼要把這些國名翻譯成中文? 中文基本上是一種不能排序的文字. 當然啦, 可以用筆劃, 注音, 王雲五發明的四角號碼或是倉頡碼來排序. 可是, 受過基礎教育的國民們, 並沒有被教育用同一種方式來對中文排序. 反之, 英文生來就是可以被排序的, 至少他的字母只有26個, 而且學過英文的人一開始就得記住這26個字母的順序, 字典也是用這個順序來排字. 而我們偉大的中華文化, 用了幾十個部首配合筆劃來編字典. 應該沒有人會背那些部首吧? 遑論他們的順序... 有了這個中文無法排序的前提, 把一堆國名用中文列出, 就是一個很白痴的行為... 全世界有四種人, 1. 看不懂中文, 看不懂英文的人 2. 看得懂中文, 看不懂英文的人 3. 看不懂中文, 看得懂英文的人 4. 看得懂中文, 也得看得懂英文的人 Case 1: 你寫什麼他也看不懂, 不知道這種人幹嘛用電腦 Case 2: 看得懂中文的人, 但不知道英文排序, 乖乖地一個一個國家找... Case 3: 看不懂中文的人, 列一大堆中文國名, 完全就是一個手足無措! Case 4: 這應該是大多數人的分類, 明明知道台灣是T開頭, 應該可以很快找到, 偏偏是列了一堆中文國名, 一大堆非洲國家, 找半天才能找到台灣... 在我看來, 這種選單應該全部寫英文, 根本不用翻譯. 如果要翻譯, 那也應該直接寫成該國所使用的語言, 而不是全部翻成"中文". 當然最好的方式是併排, 前面用英文, 採其排序, 後面加註該國語言所表示的國名... 下面是兩個壞例子... Skype Google Blogger 這樣誰有辦法很快在那一堆國名裡面找到自己要的啊??