PC Magazine reviews

果然很糟糕XD
Trend Micro Titanium Maximum Security - 3.5 points
Trend Micro Titanium AntiVirus + - 2.0 points

我總覺得Rubenking對"大"公司太客氣了，該要給幾分就應該給幾分才對，那個TAV只拿2分的話，Max Security那版怎麼會有3.5分!? 了不起只能給2.5吧，價錢貴不少耶!!

做了好幾年，基本上評security software的editor只有這傢伙比較專業而已，其他雜誌的評比其實參考價值不高，有些甚至是買的，雜誌總是要有廣告收入才能維生...
對了，今年其實Trend Micro打的是新慘品，product name有換，在開發的時候三種SKU分別是：
Entry Level = Trend Micro Titanium Antivirus + = Trend Micro Antivirus (TAV)
Mid Range = Trend Micro Titanium Internet Security = Trend Micro Internet Security (TIS)
High End = Trend Micro Titanium Maximum Security = Trend Micro Internet Security Pro (TIS pro)

基本上...新產品Titanium各SKU的feature set都比舊版的還要....陽春....有興趣研究的請自行下載試用版在VM上面玩。
附上PC Magazine的review:
TAV2011 : http://www.pcmag.com/article2/0,2817,2368610,00.asp
TIS Pro 2011: http://www.pcmag.com/article2/0,2817,2368601,00.asp

今年最棒的依然還是NIS，我自己也是這樣認為，Symantec今年這版我從Beta就開始研究了，performance跟security的 balance很棒，feature set雖沒增加什新奇的東西，不過該有的細項還做的滿易懂的，得到editor choice不為過。(performance 比他上一版好了10%左右，算是業界數一數二了)

P.S. 人家NIS跟NAV2011一樣拿4.5分，我看Trend Micro不同SKU分數差那麼多一定是哪邊出了問題XD

約耳趣談軟體 - 附錄

本書最後有讀者問了如何估計軟體開發時程，我簡單節錄約耳的回答：

如果估計的是已經細分過的任務(每個任務長度最長是一天，否則必須再細分下去)，而且評估者要有足夠的經驗，能在估計時間內包含一切(假期、整合時間、「新功能」時間、參加愚蠢經營會議的時間、面試的時間...等)，那只需要10%的緩衝時間。
但這段緩衝時間只是讓自己心安的做法，應該要根據各種類型的緩衝，還有事情的緩急來分配時間，例如：
1. 開發過程中想到的預期外的功能，針對這些新功能的緩衝時間。
2. 由於競爭者做了某些事，為了因應競爭者所需的緩衝時間。
3. 整合各個開發者所寫的程式碼，讓結果正確運行的緩衝時間(依經驗可以是從25%~100%)
4. 在測試時發現問題並修正的緩衝時間。
5. 員工必須執行開發之外的工作，例如：training課程、公司緊急會議、火警演習、準備老闆生日蛋糕...等。
6. 預防發展不順利時的緩衝時間。
7. 因應估計時漏列事項的緩衝時間。

我之前待的TM公司，manager們在列tasks時就已經常常漏列許多tasks了，也沒有在估計"整合"的時間，也常常有高層想到新的東西就硬要加進來做，當然也沒有估計過會議等雜事的時間...
不過我想犯的最大錯誤可能是讓"沒有經驗"的人來評估時程...總之一個佔公司快一半營業額的產品就這樣被搞得亂七八糟，我想過不用多久，大家就會知道了。

約耳趣談軟體 - 書中的好文節錄 part 2

軟工以及軟體公司的管理真的是很有趣的東西，PC畢竟出現時間還不長，還沒有經過時間磨練的大規模商業及管理研究，因此要從別人研究或是經驗裡學到大型軟體開發及管理實在不易。約耳這本書道出許多軟體開發及管理上的許多「事實」，真的是一本每位軟體從業人員必讀的好書。
繼續節錄裡面一些「中肯」到不行的段落。

1. 客戶不知道他們要什麼。別再期望客戶知道他們要什麼。

2. 重要推論一：把使用介面的畫面展示給非程式人員看時，如果這個介面很不好，對方會認為你整個程式也是很不好的。

3. 重要推論二：把使用介面的畫面展示給非程式人員看時，如果這個介面非常漂亮，對方會認為這個程式幾乎已經完工。

4. 重要推論四：因為政治因素要求由各技術經理或客戶「啟動」專案時，可以提供數種美術設計讓他們選擇。
改變某些元件的擺設方式，改變外觀和字型，移動標誌位置，標誌也可以變大或變小。拿些無關緊要的家家酒內容給他們玩，讓他們覺得自己很重要。這些他們就不會嚴重影響你的時程了。

5. 至少要有一個對所用的語言、類別、API以及平台有數年以上經驗的設計者，否則還是不要啟動專案吧。如果你可以選擇平台，就用你的團體最熟悉的吧，即使這個平台並不是最符合趨勢或看起來最有生產力也沒關係。另外在設計抽象機制或程式設計工具時，多做些努力讓它不會漏吧。

6. 經理人喜歡施行測量系統，而且喜歡把它和獎懲方案綁在一起。不過只要沒有百分之百的監督，工作人員就有誘因來個「下有對策」，心裡只想著那個測量系統，完全不顧工作的實際價值或品質。

7. 軟體組織通常會獎勵(a)寫大量程式以及(b)修正大量問題的程式師。想在這種組織中出頭，最好的方法就是寫一大堆錯誤百出的程式之後再全部修好，而不是多花些時間在一開始就把東西做好。

8. 除非有個程式師掌舵，否則沒有軟體公司會成功的

9.  我並不是說這是我離開Juno的原因，不過它的確解釋了我離開Juno(約耳的前公司)的理由：不管你多麼努力工作又有多聰明，也不管你是否在「負責」，你對再微小不過的事都沒有權力。把你該死的點子訓練以及聰明睿智放一邊，把那些讓我們付錢請你的一切東西通通都丟到一邊吧。而且Juno的經理很多，大概佔總員工四分之一，所以他們有的是時間可以到處亂伸手指，確定他們能掌控。在微軟卻是副總自己從九號大樓出來找你，確定你有權力能把事做完。這對比還真是強烈啊。

10.
A. 有些事需要天份才做得好。
B. 天份很難複製。
C. 有人嘗試複製天份，要有天份的人建立規則讓普通人照著做。
D. 結果所得到的產品品質很低。
「訓練」並不真的能產生一致的結果。
小心方法論。方法論可以讓每個人的表現都提升到不佳但可接受的程度，不過同時也會產生很多約束而激怒更多的聰明人。

11. 事實上如果你曾經把很關鍵的業務拿去外包，就會瞭解外包其實是個地獄。不能直接控制客戶服務，客服就會爛到不像話，爛到像某人在網誌上寫的，想在電話公司找個人(任何人都好)去做些最最簡單的事都辦不到。

12. 如果是核心的事業功能，不管是什麼都要自己來做。

13. 在開始行銷你的「精簡」產品時，你會告訴大家：「嘿，這東西很小，只佔1MB。」大家通常都會很高興，然後就會問你有沒有他們要的重要功能，如果沒有的話還是不會買你的產品。 

14. 聰明的公司試圖讓產品的互補物普及化(commoditize)。(例如，PC硬體與軟體是互補物，PC如果賣得好，隨之軟體也會賣得好，virus與防毒軟體或許也稱的上是互補物XD)

15. 無法獲得開發者尊重的產品經理沒有作用，因為他們只會一事無成。當我還在Excel團隊時，開發者會把沒有技術底子的產品經理當作早餐吃掉。

16. 產品經理最重要的技能，就是把自己的想法塞進軟體開發人員腦子裡，讓開發人員以為是自己的點子，然後乖乖照著做。

約耳趣談軟體 - 書中的好文節錄 part 1

今天把這本書看完了，節錄一些我覺得不錯的片段下來

1. 在很多程式開發組織中，出現設計爭議時，總沒有人願意做出決策(通常都是因為一些「政治理由」)，所以開發人員只去做那些沒有爭議的項目。

2. 當你和整組人一起建立產品時，通常每個人都會各有所好，因而產生各式各樣真正或虛構的必備心愛功能，如果要將這些功能全部都做出來，恐怕永遠做不完而且要花很多很多的錢。所以你必須馬上開始刪功能，而刪功能的最佳方法就是利用規格的「非目標」章節，列出我們不打算做的東西。

3. 1980年代當微軟開始快速成長時，那裡每個人都讀過The Mythical Man-Month(人月神話，這本中文版出很久了)這本軟體管理經典。這本書的主要重點是說，在進度落後的專案中增加更多程式員，只會讓進度更加落後。這是因為當團體中有n個程式師時，溝通路徑的數量會變成n(n-1)/2，也就是以O(n^2)增加。

4. 不要把程式員升為程式經理。良好程式經理所需的技能(撰寫清楚的文章，外交手腕，對市場的察覺，對使用者的認同以及良好的使用介面設計)幾乎都不是良好程式員所需的。當然有人兩者都行，不過少之又少。

5. 別讓程式人員對程式經理報告。這是很微妙的錯誤。我在微軟當程式經理時設計了Excel的Visual Basic(VBA)策略，並且訂出涵蓋最微小細節的完整規格，詳細敘述應該如何在Excel裡實作VBA。我的規格大約有500頁。在Excel 5.0開發的巔峰時期，我估計每天早上有250人來上班，主要任務就是要實作我寫的這份龐大規格。我完全不知道這些人是誰，不過Visual Basic組就有十幾個人光是在寫這玩意的文件(更不用提寫Excel的文件或是全職負責說明檔內超連結的人了)。不過最誇張的是我位在這層層結構的「底層」。沒錯。沒有人要向我報告。如果想讓大家去做某件事，我必須說服他們這件事該做。當主開發師Ben Waldman不想做我規格定義的某個項目，他跳過不做就好了。當測試人員報怨規格中某個項目不可能做完整的測試，我就得去把這個項目簡化。如果這些人得向我報告，產品可能不會這麼好。...凝聚共識的決策型式卻是做對事的最好方法。

6. 當你一直往上把事情弄得太抽象，就會像上太空一樣沒有氧氣。有時候這些聰明的思想家就是停不下來，然後就創造出這些荒唐又無所不包的高層次宇宙景像，這些東西什麼都好，就是完全沒有實際的意義。
這種人我稱之為架構太空人。要他們寫程式或設計程式是難上更難，因為他們沒法子不想架構。叫太空人是因為他們活在氧氣層之上，我不知道這些人是怎麼呼吸的。他們通常在真正的大公司上班，只要這種公司才養得起大批不事生產，完全沒有貢獻的高學歷份子。

7. Alfie Kohn在哈佛商業評論中一篇已成為經典的文章中寫道：
過去三十年間至少有兩打以上的研究明確地指出，為了報酬而工作的人，表現不如完全不期望有報酬的人。
他的結論是「激勵(或者說賄賂)在職場上是行不通的」。DeMarco和Lister更進一步明白地表示，任何型式的職場競爭及獎懲方案，包括以前流行那種「在某人做對事時馬上獎勵」的把戲，所帶來的傷害都大過好處。給某些人正面激勵 (比如愚蠢的公開頒獎儀式)暗示他們其實只是為了拿那個壓克力獎牌才有表現；也暗示他們在工作上不夠獨立，要有甜頭才會努力；這實在是既侮辱又貶低人格。

8. QA的主管應該有否定權，可以阻止發行不合格的軟體。

9. 就個人層次來說，你曾經注意過某件事嗎？叫某人做一個工作可以做得很好，可是如果給他兩個工作，他會把其中一個做好卻忽略另一個，不然就是兩件工作都做得很慢，慢到你覺得懶鬼都比他勤勞。這是因為程式設計的工作就是需要很長的切換時間。

10. Netscape 6.0第一個公開的beta版終於出來了。5.0版從來沒出現過，最後一版重大改版是大約三年前發行的4.0版。在Internet世界裡三年的時間長得可怕。就在這段時間中，Netscape只能無望地坐看市場佔有率直線下降。...他們做了一個每家軟體公司都可能犯的一個最糟的策略錯誤：
他們決定把程式從頭重寫過。

11. 讀程式比寫程式困難

12. 新程式碼比舊程式碼好的想法顯然是很荒唐的。舊程式碼已經被用過也被測試過。很多問題都已被找出來並被修好。它並沒有什麼問題，不會因為在你的硬碟裡放久了就生出新的問題。...當你把程式碼丟掉從頭重寫時，其實是把這所有的知識都丟掉了。這所有已修正的問題，好幾年的寫程式的成果。...你會讓出市場領導地位。你會把兩三年的時間當禮物送給競爭者。相信我，軟體的一年可是很長的。...你會讓自己陷入一個極端危險的位置，到時候會有很多年都只能發行舊版程式，完全無法因應市場需求的新功能而改變策略，因為你沒有可以發行的程式。這段時期最好還是把公司收起來算了。...你會浪費大量的資金去撰寫已有的程式。

13. 你一定要記住，在要從頭重新開始時，完全沒有理由相信這次會做得比第一次好。首先你的程式團隊根本不可能和當初相同，所以並不會真的有「更多的經驗」。你其實只會把大部份的舊錯重新再犯一次，另外再多加一些舊版本沒有的新問題。


這本書實在是太精采了，一堆名言，下篇待續。

約耳趣談軟體

最近在看這本書，雖然說基本上書裡的內容都可以從約耳的blog讀到，但是有本書在手上翻感覺還是不一樣。
這本書基本上是在講一些開發及管理軟體project時的一些「實務經驗」，還有一些法則，有在軟體公司上班一段時間的看了這本書一定會會心一笑，即使是在國內數一數二的大型軟體公司，約耳所提到一些對軟體開發及管理有害的事情還是不斷再發生...

http://local.joelonsoftware.com/mediawiki/index.php/%E9%A6%96%E9%A0%81
有興趣的可以到這個網頁看看^^

貼一張一點關係都沒有的圖

PC magzine的review

果然是慘到爆^^

有興趣請到這參觀"http://www.pcmag.com/article2/0,2817,2352674,00.asp"
之所以會這麼爛我想原因有很多，不過我認為最值得公司檢討的地方是「公司策略」。
1. Resource分配，2008跟2009兩版大概都花了40名工程師去做，2010這版公司認為只要小改版就好，所以砍到剩10個左右，而且這10個人還常常去支援做OEM版本...這樣能做出啥好東西出來？
2. 前面提到OEM版本，公司策略就是要讓marketing盡量去找OEM vendor合作，綁防毒軟體賣，每一家OEM vendor都有自己不同的customization，都需要花一些人力下去做，但是好像都沒有人hire進來...

實在懶得寫了，反正我現在就是拿薪水做該做的事就是了，沒分紅，公司也不注重technical，做核心技術的面對不到客戶，也沒有什麼危機感，我這做product我想就每年做出個隨便的東西交代過去就好了，反正公司是靠marketing賺錢的，營業額成長底下的工程師又不會拿比較多Orz.