近一個月來，努力撰寫排水溝分析程式，突然感到最花時間的地方，其實不是在寫程式碼，而是反覆地在改資料結構和演算法。臺灣人最會自作聰明之處，就是在看完別人的資料結構和演算法後，緊接著說：「這個我也會，我花XX天的時間就可以寫出來了。」不要用我的資料結構和演算法，尤其是不能使用我的演算法，重頭開始寫到跟我一樣的進度，請你仔細評估一下究竟需要花多少時間呢？
傳統的程式設計問題1 + 2 + 3 + … + N = ?，而且考慮N為任意正整數和大數運算原則，緩慢的計算方法是連續加總得結果，快速的計算方法是梯形公式直接求解，此處的連續加總和梯形公式都是演算法。若是演算法不佳，資訊同行會說爛方法兼沒技術，不想被人這麼品頭論足，就得花點時間想演算法。以上，都是屬於可以直接求解的問題，而歸類為不能直接求解的問題，程式設計師常會問起業主：「你的計算流程大概怎樣？…」有些工程設計根本沒有流程，僅僅是反覆地在試誤取得差不多的解。雖然，已經儘量不咬文嚼字，但是仍想更白話的說：「重點是你打算怎麼解？」
程式設計真正困難之處在於演算法，要是耍白目想讓業主確實了解其困難性，就是按照他的意思將程式碼寫出來，然後讓他知道他的想法不可行。業主頭一次遭到挫折，想必應該還是自信滿滿，再照一次他的意思寫給他看，然後再讓他知道第二次想法仍然不可行。想當然耳，事不過三就已經可以體會到演算法有多困難，尤其是必須在有限時間內解出問題，常常會遭遇困難於計算之處。演算法往往和資料結構互相牽連，所以兩者相互間會改來改去，因而得反覆如此直到近乎完善為止。
傳統的程式設計問題1 + 2 + 3 + … + N = ?，而且考慮N為任意正整數和大數運算原則，緩慢的計算方法是連續加總得結果，快速的計算方法是梯形公式直接求解，此處的連續加總和梯形公式都是演算法。若是演算法不佳，資訊同行會說爛方法兼沒技術，不想被人這麼品頭論足，就得花點時間想演算法。以上，都是屬於可以直接求解的問題，而歸類為不能直接求解的問題，程式設計師常會問起業主：「你的計算流程大概怎樣？…」有些工程設計根本沒有流程，僅僅是反覆地在試誤取得差不多的解。雖然，已經儘量不咬文嚼字，但是仍想更白話的說：「重點是你打算怎麼解？」
程式設計真正困難之處在於演算法，要是耍白目想讓業主確實了解其困難性，就是按照他的意思將程式碼寫出來，然後讓他知道他的想法不可行。業主頭一次遭到挫折，想必應該還是自信滿滿，再照一次他的意思寫給他看，然後再讓他知道第二次想法仍然不可行。想當然耳，事不過三就已經可以體會到演算法有多困難，尤其是必須在有限時間內解出問題，常常會遭遇困難於計算之處。演算法往往和資料結構互相牽連，所以兩者相互間會改來改去，因而得反覆如此直到近乎完善為止。
