我們應該慢慢的發展，因爲它會迫使我們儘早優化。在慢速機器上開發是否過早優化？
蘭德爾海德指出了The Fallacy of Premature Optimization，有很多圍繞霍爾報價誤解：
我們應該忘記小的效率，講的時候約97％：過早的優化是根所有的邪惡。
特別是，儘管今天的機器比霍爾的那一天更尖叫，但並不意味着「應該避免優化」。當我建議我們應該以適度的速度發展時，我尊敬的同事也有一點意見嗎？這個想法是，性能瓶頸對慢速盒子更加惱人，所以他們很可能會受到關注。
慢速計算機不會幫助您找到性能問題。
如果你的測試數據在一個表中只有幾百行的分貝將緩存這一切，你永遠也找不到寫的不好的查詢或壞表/索引設計。如果您的服務器應用程序不是多線程服務器，那麼您將無法找到該服務器，除非您用500個用戶對其進行壓力測試。或者如果應用程序瓶頸帶寬。
優化是「一件好事」，但我對新開發誰擁有各類關於如何更好地做到這一點的想法說「我不在乎你給我的速度有多快錯誤的答案」。先找到它，然後在找到瓶頸時加快速度。一位經驗豐富的程序員將開始設計併合理開發。
如果性能非常關鍵（實時？毫秒交易？），那麼您需要設計和實施一套基準和工具，以科學地證明您的變化使其變得更快。有太多的變數會影響表現。
此外還有經典的程序員的藉口，他們會帶出 - 「但它的運行速度慢，因爲我們故意挑慢的電腦，它會運行得更快，當我們部署它。」
如果你的同事給他一個緩慢的計算機，並讓他負責的「表演」 :-)
沒有緩慢的開發者箱子，我什麼時候會有時間去SO;） – JoelFan 2009-10-21 19:42:38
這應該是社區wiki，因爲它很主觀，沒有「正確」的答案。
這就是說，你應該開發可用的最快的機器。是的，任何慢的都會引起刺激，並鼓勵你修復減速，但價格非常高：
作爲一名程序員，你的工作效率直接關係到你頭腦中可以容納的東西的數量，減慢你的過程或者阻止你，這會延長你在短期內持有這些想法的時間 - 記憶，使你更容易忘記它們，並且必須重新學習它們。
等待編譯的程序允許一堆錯誤，潛在的問題和修復在你分心的時候掉下來。正在等待加載對話框，或者查詢完成以類似方式中斷您。
即使您忽略了這種效果，您仍然可以得到後面陳述的真相 - 早期的優化會讓您在圈子中追逐自己，破壞已經工作的代碼，猜測（通常精度不高）事情可能會陷入困境。首先設計好你的代碼，然後你可以忘記優化，直到有機會解決一段時間，此時任何必要的優化都將是顯而易見的。
這也是我的看法。開發速度對於競爭力往往是至關重要的。但是我想補充一點，在慢速機器上測試*可能是很好的選擇，特別是如果代碼是用戶界面的話。 – liori 2009-10-21 16:38:09
測試您的客戶將要使用哪些內容，這可能意味着具有受限用戶帳戶（如果您使用Windows）或不具有sudo權限的用戶帳戶（OSX/Linux /其他基於Unix的系統）的低端機器。 – 2009-10-21 17:06:00
取決於您的交貨時間。如果你在12個月的交付週期內，那麼你應該開發一個速度快的盒子，因爲你的客戶從現在開始的12個月的平均箱比現在的「平均」要好。
隨着您的開發週期接近「今天」，您的開發機器應該接近客戶機箱的當前「平均」速度。
有人不喜歡現實世界的編程嗎？是的，這將是很好的總是有最大的最壞的發展框。如果您的客戶在完成時無法運行應用程序，那就不太好了。 – jmucchiello 2009-10-21 19:50:23
我想這將取決於你在做什麼以及目標受衆是什麼。
如果您正在編寫用於固定硬件（比如控制檯遊戲）的軟件，那麼使用與您將部署的設備相似或相同的設備（至少測試設備）。
如果您正在開發桌面應用程序或其他領域的應用程序，然後開發任何您想要的機器，然後調整它，然後運行所需的最小規格硬件。同樣，如果您正在開發內部軟件，那麼公司想要購買的機器可能會有最低規格。在這種情況下，在快速機器上開發（以減少開發時間和成本），並根據最小規格進行測試。
底線，發展最快的機器，你可以得到你的手，和測試上的最低或精確的硬件，你會被支持的。
我通常在最快的機器上開發，我可以讓我的手。
大部分時間我正在運行一個調試版本，這已經夠慢了。
對科德的愛情，使用分析工具，沒有發展緩慢機認爲它很重要！
不錯！ http://en.wikipedia.org/wiki/Edgar_F._Codd – 2009-10-21 17:36:15
應該避免優化，是不是給了我們Vista？ ：p
但是總的來說，它總是一個折衷的問題。要問自己的重要問題
您的最終用戶將使用哪種平臺？ 我可以放棄週期嗎？如果我這樣做會發生什麼？
我同意大多數情況下最初的開發應該在最快或效率最高的機器上完成（不是相同的）。但是對於運行測試，在目標平臺上運行測試，並經常和早期進行測試。
如果您的硬件是接近最終測試和生產環境的編程，你會發現有少惱人的意外，當談到時間釋放的代碼。
我已經看夠了程序員們一邊刷卡嚴重的，反而造成自己的機器比其大部分用戶的方式更快的意想不到的問題。但是，我也看到數據發生同樣的問題。代碼在一個小數據集上進行測試，然後在大數據集上「崩潰」。
開發和部署環境的任何差異都可能是意外問題的根源。
儘管如此，由於編程昂貴且耗時，如果最終用戶運行緩慢的過期設備，更好的解決方案是在測試時處理它（並在幾個早期測試中安排檢查可用性和時間）。
爲什麼會因爲您擔心錯過潛在問題而癱瘓您的程序員？這不是一個理智的發展戰略。
Paul。
我認爲這是一個合理的概念（但也許是因爲它適用於我）。
如果我的開發人員工作站速度太快，我發現我並不認爲通過簡單的思路是因爲在重新生成軟件映像或將其下載到目標時幾乎沒有時間懲罰。我會說至少有一半的下載是不必要的，因爲我只記得在我要調試代碼之前我錯過了一些東西。
目標機器可能包含一個受限制的處理器。如果 - 在嵌入式MCU上 - 你有一半的FLASH，RAM和時鐘週期每秒的機會，開發人員在設計代碼時會更加小心。我曾經在數據區（不是在RAM中，而是在一個串行eeprom中）提供了字節變量，並收到了「我們不需要小氣。」的回覆。幾個月後，他們達到了RAM上限（128KiB）。我的反映是，對於這個應用程序，從來沒有任何記錄大於256字節，因爲沒有RAM來複制它們。
對於服務器應用程序，我認爲有一個（很多）性能較低的硬件可以測試是一個好主意。兩個或四個核心，而不是十六個（或更多）。 1.6 GHz istdo 2.8。名單繼續。通常服務器 - 由於每個人都在談論它 - 這是系統架構的瓶頸。在開始爲它開發（服務器）應用程序之前就已經很久了。
這真的需要成爲社區維基，如果它保持開放。而爲了記錄，在慢速機器上開發是一種討厭工作的好方法。 :)但是，在慢速機器上測試可能是一個合適的中間立場。 – 2009-10-21 16:34:07
不是由霍爾引用。 – 2010-02-22 21:57:55