開発者に遅い開発マシンを与えると、コードはより速く/より効率的になりますか？[閉まっている]

開発者に絶叫する高速マシンを提供するとします。WPFベースのVS2010は非常に高速にロードされます。次に、開発者は、自分のボックスで正常に動作するWPFまたはWPF / eアプリケーションを作成しますが、現実の世界でははるかに低速です。

この質問には2つの部分があります...

1）開発者に遅いマシンを提供するということは、結果のコードがより高速またはより効率的であることを意味しますか？

2）開発者に高速のIDEエクスペリエンスを提供し、「典型的な」ランタイムエクスペリエンスを提供するにはどうすればよいですか？

更新：

記録のために、経営陣に対して率直な対応を準備しています。これは私の考えではありません。あなたの人々は、クライアントの誤った要求を修正するのを手伝っています。より多くの弾薬と、これにいつどこでアプローチするかについて言及してくれてありがとう。次のような有効なユースケースを+1しました。-
特定のサーバー側プログラミングの最適化
-テストラボ
- 最高品質のグラフィックカードではなく、より良いサーバーを購入する可能性

絶対に

また、管理者がすべての会議をピグラテンで行う必要があることも事実です。簡単な文章を話すときに不利になるように、全体的なコミュニケーション能力を向上させます。彼らは彼らのポイントを得るために顔の表情とボディーランゲージにもっと頼らなければなりません、そして、私たちは皆、とにかくすべてのコミュニケーションの少なくとも70％であることを知っています。

CFOは、そろばんとチョークのみを使用する必要があります。さもなければ、彼らは「生データ」に頼りすぎてしまい、「直感」に十分ではなくなります。

そして、副社長以上は、ゴルフ場のような気を散らすような環境で、すべての重要なビジネス会議を半酔状態で開催する必要があります。ああスナップ...

答えは（大胆に言う）常に

いいえ。

予算内で最大限の成果を上げ、展開する機器のmin-max仕様範囲でテストします。

エミュレーター、仮想マシン、テスターを備えた実際のマシンがあり、すべてパフォーマンスをテストしてそれが要因かどうかを確認できます。

1） 非常に、ありそうもない。いいえ、あなたの開発者はそれを提案するためにあなたのコーヒーに厄介なものを入れるかもしれません。開発者が、コードがコンパイルされるのを待つ時間、またはIDEが実行していること、またはコードの改善に費やしていない時間を待つ時間。彼らの精神的な流れも破壊します。問題に心を留めれば、彼らはその問題をより効率的に解決するでしょう。

2）実際にサポートしたい最低スペックを表す2台目のPCをそれぞれに提供し、KVMスイッチを使用して実際のワークステーション間を行き来します。

長いコンパイル時間が好きです。履歴書を作成する時間が増えました。

これはひどい考えです。開発者は可能な限り生産的であることを望みます。つまり、可能な限り高速なマシンを提供することを意味します。そのため、開発者は1日中じっとコンパイルを待つことはありません。（わずかにOTですが、WebSenseなどで潜在的に役立つサイトへのアクセスをブロックしないようにすることも役立ちます。）Stone-Ageテクノロジーを実行しているユーザーがいることに制約されている場合は、テストマシンが必要です。同様の仕様で、テクノロジーの選択に関して間違った道を進んでいないことを確認するために、早期かつ頻繁にテストするようにしてください。

開発は実行可能な最高の環境で行われるべきです。テストは実行可能な最悪の環境で行う必要があります。

遅いマシンが与えられた場合、開発コードの最適化ではなく、開発プロセスの最適化に1日費やしていました。だから：いいえ！

組み込みシステムプログラマーは常にこれに遭遇します！また、2つの部分から成るソリューションがあります。

1. 要件では、YハードウェアでXパフォーマンスを指定する必要があります。
2. Yハードウェアでテストし、Xパフォーマンスが得られない場合は、バグを報告します。

その場合、開発者がどのハードウェアで作業するかは重要ではありません。

それができたら、より高速な機器でプログラマを1日30分、または1年で125時間節約できるとしましょう。そして、彼らは利点とオーバーヘッド（シリコンバレーのために途方もなく低い）で100,000ドル、または1時間50ドルの費用がかかるとしましょう。125時間* 50ドル/時間は6250ドルです。したがって、プログラマー1人あたり年間6250ドル未満をロッキン開発ハードウェアに費やせば、お金を節約できます。

それがあなたの経営陣に伝えるべきことです。

ティム・ウィリスクロフトは、コメントの中でこれの前半をほとんど言っていました、そして、公正な世界で、彼はこの答えが得るあらゆるポイントの半分を得るでしょう。

10月24日追加：

私の元雇用者はその理論を持っていました、そして、それは彼らが約1億ドルを怒らせるのを助けました。

彼らは、日本、韓国、中国でプログラマーを雇うために使用された、日本を拠点とするコングロマリットです。そこの人々は、安っぽい開発ハードウェアを使うこと、13時間の勤務日、机で寝ること、そして人生を持たないことでクールです。そのため、有名なシリコンバレーの会社を買収してLinuxベースの携帯電話OSを開発したとき、現代のギアを欲しがっている愚かなカリフォルニア人は、ちょっとしたプリマドナであり、実際には（生産性のような）正当な理由はありませんでした。

4年後、OSはがらくたのように動作し、すべてのスケジュールが吹き飛ばされ、顧客は腹を立て、左右の契約を終了しました。最後に、OSプロジェクトは取り消され、コングロマリットの世界的な労働力の大部分が昨年中に解雇されました。そして率直に言って、私はそのお金と努力がどこへ行ったのか株主に説明しなければならなかった幹部の一人になりたくなかったでしょう。

この大失敗を引き起こしたのは、遅い開発マシンだけではありません。他にも多くの戦略的および戦術的な失敗がありましたが、それらはinで働く人々が列車の残骸が来るのを見ることができるのと同じ種類のものであり、なぜ意思決定者ができないのか疑問に思いました。

そして、遅いギアは確かに要因でした。結局のところ、時間通りに配信するために銃の下にいる場合、意図的に作業を遅くすることは本当に賢いことですか？

プログラミングでは、「時期尚早な最適化がすべての悪の根源である」という古い言葉があります。私はあなたがすべての悪の別の「ルート」（または少なくとも最初のブランチ）をうまく作成できたと思います。これからは、「開発者の早期の最適化解除はすべての悪の根源である」と言えます。

要するに、答えは開発時間を遅くするだけで、それ以上のメンテナンスがより難しくなるということです。コンパイル時間が長くなり、ディスク上のコードの検索が遅くなり、オンラインでの回答の検索に時間がかかります。そして、最も重要なことには、開発者は必要な機能をテストできるように、コードを時期尚早に最適化し始めます。

その最後の点は最も重要な問題であり、他の多くの回答では取り上げられていません。最初のバージョンは大丈夫かもしれませんが、将来コードを更新したい場合、開発者の時期尚早な最適化がコードの焦点を良いデザインから遠ざけ、「これを作る」に近づいたことがわかります「私の仕事を維持するための最小限の作業」スタイルのコード。追加の機能を追加することは、その時点で選択された最適化が不要であり、他の半最適化されたハックの上に半最適化されたハックのパスにコードをロックするため、より困難になります。

この例として、現在のバージョンの最小システム要件が、速度がやや遅いシングルプロセッサマシンであることを想像してください。このボックスに開発者を配置すると、彼らは製品を迅速に開発したかったので、多くのハックに依存する複雑なシングルスレッドソリューションを思い付きます。5年後、デュアルプロセッサマシンの最小要件を持つ製品の新しいバージョンができました。並行して実行できるプログラムの部分をきれいに分離できるようにしたいのですが、5年前に開発者がハッキングソフトウェアを作成することを余儀なくされた決定により、新しい最小要件を最大限に活用できなくなりました。

開発サイクルの最後にフェーズを追加して、下限ボックスで受け入れテストを行う必要があります。確かに、開発者のマシンが高速であるため、コードの一部は遅すぎますが、その部分を分離して最適化することができます。コードの残りの部分は、クリーンで維持可能です。

あなたの質問は、「開発者に貧弱な開発者のマシンを与えることで、開発者に早期に最適化を強制することはできますが、それでも良いコードを取得できますか？」そして答えはノーです。

興味深い読書、それらすべての答え。

しかし、私はここで答えているほとんどの人がポイントを逃していると思います。私が読んだ質問は、開発者にコードを高速化するためのP1を実際に提供することに関するものではありません（少なくとも）。

要点は、今日の多くのソフトウェアは、はるかに強力なコンピューターにもかかわらず、前の千年紀に使用していたソフトウェアと同じくらい、またはさらに遅いということです。ここでの回答から判断すると、ほとんどの開発者はそのヒントを得ていません。これはWebアプリケーションでは非常に明白です。このサイトは非常に良い例外ですが、多くのサイトでは1 MBのフロントページがあります。それがダウンロードされるのを待つために何が得られますか？知りません。私は、ユーザーがそれに費やす必要のある時間を尊重していない開発者からの無知、またはMBごとに支払う場合のさらに悪い支払いについてだと思います。問題は、これらすべてのWebページに高解像度の画像が含まれていないことです。多くの場合、一部の開発環境から配信される単なるくだらないコードです。もちろん、それは私が推測するがらくたコードではありませんが、ユーザーとしての利益はありません。

一般的に、それはコードを最適化することだけでなく、それが与えるよりも遅くなるものを含めないことを選択することと同じくらい重要です。

数週間前、1995年からラップトップを始めました。Windows3.xはすぐに稼働しました。データベースでは、Enterキーが完全にリリースされる前に（少なくとも少なくとも）いくつかのデータを開始する必要があります。

今日、私たちはソフトウェアからより多くのものを得ていることを知っていますが、コンピューターの数倍も速くなっています。開発業界が1995年以降のソフトウェアの速度を維持し、新しい機能を必要とするために新しいハードウェアを購入させようとしないのはなぜですか。今日では、日常のプログラムやWebサイトが、以前とまったく同じことを行うために新しいハードウェアを購入するように人々に強いているようです。しかし、もちろん、より手の込んだ方法で。

私は、Linux開発がこれをうまく処理しているように思われると言わなければなりません。Linuxディストリビューションは長年にわたり、アニメーション化されたウィンドウのような多くの目を楽しませるような空想的なウィンドウでさえもはるかに先を行ってきました。問題は、彼らが今日のコンピューターでも昨日のコンピューターでも機能しているにもかかわらずです。最先端のハードウェアだけでなく。

今では、多くの開発者が不健康なレベルのアドレナリンを持っていると思います。はい、私は目の前で待っているすべてからフラストレーションを返す方法を見つけました：
オフィスSQLサーバー（管理コンソールの起動）arcgis（起動と使用）acrobatリーダー（起動）agresso（少なくともWebアプリケーションとして） Windows（見つめて使用しています。まだ7つは試していません）.net Webページ（ダウンロード）

等々

良い感じ ：-）

乾杯
ニクラス

1）開発者に遅いマシンを提供するということは、結果のコードがより高速またはより効率的であることを意味しますか？

私たちは過去60年間ソフトウェアを構築してきましたが、まだこのような質問がありますか？コーナーをカットするさらに別の試みのようです。攻撃はありませんが、質問は論理的だと思いますか？これらの用語で考えてみてください（可能な場合）：過酷な条件、雨、泥など、あらゆる状況で動作できる4x4の車両を構築したいと考えています。結果として得られる車両がそれらで動作できることを確認するためだけに、エンジニアと組立ラインを要素の下に配置しますか？

つまり、イエス・キリスト！開発とテストがあります。テストは別の厳しい環境で行われるか、開発者はストレステストに適した方法で自分の開発環境にテストベッドを組み立てる方法を知っています。できない場合は、彼をより良い開発者に置き換えてください。

2）開発者に高速のIDEエクスペリエンスを提供し、「典型的な」ランタイムエクスペリエンスを提供するにはどうすればよいですか？

開発者にそれを尋ねる必要があります。そして、彼らがあなたに客観的で有効な答えを与えることができないなら、あなたは彼らを実際の開発者に置き換える必要があります。

しかし、質問を楽しませるには、開発者（優れた開発者がいると仮定）、優れたツール、優れたハードウェアを、できるだけ余裕を持って与えてください。次に、ソフトウェアが動作する必要のある最も一般的なベースライン環境をセットアップします。それがありますテストが行われるべき場所。開発環境とは別のテスト環境（できれば、ストレステストを行うことができる環境）を用意することをお勧めします。

もしあなたの開発者が良ければ、彼らはあなたにこれを伝えたはずです（あなたが彼らに尋ねたと仮定して）。

その結果、多くのbitchin '開発者がいます。このようなものは、それだけで十分に難しいので、体験を悪化させないようにしましょう。

ただし、テストまたはQA環境のユーザーと同様のハードウェアを使用して、パフォーマンスの問題を解消することをお勧めします。良い考えです。

彼らがサーバーソフトウェアを書いているのなら、私は規範に背を向けて「はい」と言います。あなたが望むすべてを笑いますが、私が今まで見た中で最も効率的なチームは、Wyse端末を備えたPerlのグループです。これは1990年代後半で、大学の分社であり、彼らは空間グリッドソフトウェア（基本的に計算のみ）を書いていました。しかし、彼らは比較的強力な後期モデルのRS / 6000と話をしていました。

イベントに興味を持たせるために、そこには盲目のプログラマーがいました。とても感銘を受けました。

これは悪い考えではありませんが、開発者に迅速なプログラミング環境を持たせたいと考えています。

プログラマーに2つのマシン（テスト用の高速な開発用ボックスと低速なコモディティボックス（おそらく仮想））を提供することで、これを実装できます。

VSビルドプロセスを少し調整すると、リモートデバッグを使用して、テストボックスへの展開が一般的になります。

コーダーに、より効率的なコードの開発を強制することを検討する他の方法があります。たとえば、ユニットテストにパフォーマンスとメモリ使用の目標を含めることができます。メモリ使用の予算を設定することも、優れた目標です。HTMLコードのページウェイト予算も設定します。

問題は、開発者が高速マシンで非効率的なコードを作成することではなく、測定する必要があるパフォーマンスメトリックを定義していないことです。

製品要件の一部として、必要なカスタマーエクスペリエンスに基づいてすべてのコンピューターで測定できる特定のターゲットを定義する必要があります。コンピューターを他のタイプのコンピューターに関連付けることができる多くのWebサイト（SpecIntを確認）があります。

これには多くの理由があります。最小限のサポート対象ハードウェアをより簡単に定義できるため、顧客からの苦情の数を制限できます-ほとんどのソフトウェアがほとんどのコンピューターで実行されるのはパフォーマンスの問題です-最小要件の範囲の人々が仕様を設定する場合合理的に許容可能なパフォーマンスがあり、顧客の苦情を制限します-そして、顧客が電話をかけると、ベンチマークを使用して、本当に問題があるかどうか、または顧客が製品の動作に満足していないかどうかを判断できます。

開発用のコンピューターの速度が遅いとコードが高速になると確信していますが、これには代償が伴います。理論的な理由は、この最初の経験をしたことです：通勤時間が長いため、電車で仕事をするためにネットブックを購入しました。すべてが非常に遅いため、このネットブックで何かが耐えられないほど遅いときに非常にすばやく表示され、遅いスポットをはるかにすばやく認識します（常にベンチマークする必要はありません）。ネットブックでの作業は、私の開発方法を大きく変えました。

そうは言っても、私はこれを、特にプロの環境で行うことを推奨していません。まず、それは士気を低下させます。ほとんどすべての人がそのアイデアを言ったという事実は、プログラマーがそのアイデアにひどく反応していることを示しています。

第二に、すべてを遅くするということは、高速マシン（たとえば1分かかる）で実行したいことは、遅延マシンなどで低速マシンでは実際には実行できないことを意味します。これはインセンティブの問題です。

最後に：生成されたコードはより高速かもしれませんが、ほぼ確実に生成に時間がかかります。

ポイント1、NO！Studioは適切なマシンで実行することを目的としており、その要件は各バージョンでさらに強力になっています。IntelliSenseをオンにして、シングルコアの非HTボックスを使用すると、実際にスタジオの一部のバージョンをロックできます。

＃2を指すために、テストプロジェクトにはいくつかのリソースを調整できる機能があります。彼らは完璧ではありませんが、彼らはそこにいます。VPCまたは低スペックのVMイメージも同様に制約されるという非常に良い仕事です。時々、ユーザーが要求した機能の意味を確認できるように、テストを行うために悪いマシンに座ってもらいました。

いいえ-実際、テストはそれほど多くないため、プロファイラーなどの余分なツールを使用しないため、より多くのバグが発生します。余裕のある最高のマシン（ゲーム開発やグラフィックショップの場合はグラフィックアクセラレーションハードウェアを含む）を提供し、VM内でテストしてもらいます。VMの仕様は、必要に応じて拡大または縮小できます。

これは興味深い質問だと思いますが、すぐに「ノー」になることはありません。私の意見は、どのような開発チームが話しているかによって異なります。例：毎年開催されるICFPプログラミングコンテストに参加しているグループを率いる場合、HPCクラスターでの短い開発時間の後に良い結果を得ても、必ずしもあなたが見つけた解決策が良いとは限りません。科学的アルゴリズムまたは数値アルゴリズムを作成している場合も同じことが言えます。64MBのメモリを搭載した古いAMD Duron 600 MHzでは、物事の遂行方法に注意する必要があり、これは一部のデザインにも影響する可能性があります選択肢。

一方で、賢いプログラマー/科学者/とにかく慎重になることになっているものは何でも。しかし、コンピュータがまったくなく、紙にメモを取らなければならなかったときに、自分の最高のコードを書き留めていることに気づきました。IDEが厳密に必要な場合、これは巨大なフレームワークを含む大きなプロジェクトには適用されない場合があります。

1つ確かなことは、高速なマシンとすぐに良い結果が得られることで（悪い）プログラマーが台無しになり、コンピューター上で見つけたがらくたの一部の理由の1つになる可能性があることです。

8コアの8Gマシンでビルドするのに約1時間かかるパッケージで作業しています（完全クリーンビルド）。また、テスト対象の比較的低価格のラップトップも持っています。ローエンドのラップトップは、1営業日中に2つのフルビルドを管理しません。

ラップトップでいくつかの意図的なテストを行うことで、高速マシンで生産性が向上しますか、それともすべてのビルドをラップトップで実行する必要がありますか？

これらは数字で構成されていないことに注意してください。

通常は毎日クリーンビルドを行う必要はないという点で、リグ付きのデモです（単一のモジュールで多くのテストを実行できます）が、部分的なビルドでさえ、コンパイル/リンク時間にほぼ1桁の違いがあります。

本当の問題は、遅いマシンでは典型的なビルドで十分な長さでコーヒーを飲むことができ、速いマシンでは少量のコーヒーしか飲めないということです。

仕事を成し遂げるという観点から、私は高速マシンで開発を行うことを好みます。納期をはるかに確実に守ることができます。一方、管理者が遅いマシンで開発を行った場合、もっと多くのWebブラウジングを行うか、少なくとも本を読むようになると思います。

興味深いことに、私はスタートアップで働いていましたが、そこで私たちはこれをやり遂げました。実際にかなりうまくいったと思いますが、それは私たちがいる特定の状況のた​​めだけです。それはクラスの自動リロードが実際に正しく働いたmod_perlショップでした。すべての開発者は、選択したIDEとしてvimを使用しました（またはいくつかのリモート編集ソフトウェアを使用しました）。最終的な結果は、コードのコンパイル/リロードなどを待機している時間がほとんどない場合です。

基本的に、私はこのアイデアIFFがすべての開発者の開発サイクルにごくわずかな影響しかなく、コードのランタイム操作にのみ影響することを気に入っています。コードがとにかくコンパイル、前処理などされている場合、開発者が作業している「バグ修正、テスト、次」ループに時間を追加しています。

対人関係の観点から、人々は遅いサーバーを使用することを強制されませんでしたが、遅いサーバーを使用した場合、あなたはあなた自身のメンテナンスやセットアップをする必要はありませんでした。また、このセットアップは最初から存在していたため、これを確立された開発チームに販売しようとすることは想像できません。

元の質問を読み直した後、私を永久に恐怖に陥れるのは、実稼働環境とは異なる開発環境です。開発用ワークステーションに影響を与えることなく、実行時に障害を発生させる可能性のあるVMをコード実行に使用しませんか？最近、私はVirtualBoxを使用/愛用しています。

ここでもトレンドに逆らうつもりです。

逸話：私は286台のコンピューターを486-esにアップグレードしたオランダのソフトウェア開発会社で働いていました（はい、私は古いです）。数週間以内に社内ライブラリのすべてのパフォーマンスが50％低下し、バグが増加しました...少しの調査では、人々はデバッグプロセス中にコード自体を検討しなくなったが、連続したコードを「迅速に」使用することが示されました->コンパイル->テスト->修正（コード）などのサイクル。

関連：米国で同じ会社の子会社を始めたとき、ロシアのプログラマーを採用することになりました。ロシアのプログラマーは、より少ない機能/少ない電力のPCに慣れており、より効率的なコーダーでした。

私はこれらが異なる時代であり、リソースが今日よりもはるかに少ないことを認識していますが、ハードウェアの面で行われたすべての進歩により、最終的な結果はどのように前進するかということに驚かされることはありませんより高い最小スペックを必要とするゆるやかなプログラミングによって否定されます...

したがって...プログラマは、「平均的なジョー」の計算能力とハードウェアの仕様を超えないマシンでアプリケーションをテストすることを余儀なくされるべきだと思います。

ハードウェアは開発時よりも低コストです。

ほとんどのボトルネックはクライアントPCではなくデータベースにありますが、開発者よりも遅いマシンでテストすることは許されません。テストツールを使用して最適化をテストします。

絶対違う。プログラマに最高のラップトップマネー、選択したキーボード、複数の大画面、プライベートオフィス、電話なし、無料のソフトドリンク、必要なすべての書籍（関連する）、主要な技術会議への毎年の旅行、素晴らしい結果が得られます。次に、上限および下限のハードウェア/ソフトウェア/ブラウザ/帯域幅の組み合わせでテストします。

これは興味深い考えです（開発者に低速のマシンを与えると、より最適化される可能性があります）。

ただし、ソリューションはより良い方法でフレーム化されています。応答時間をプログラムの要件に入れ、テスト用にローエンドのマシンを用意します。

また、非常に優れたコンパイラ/言語を使用している場合、さまざまな方法でコードを生成し、最適なものを選択できる可能性があります。それは、より高速なコンピューターによってのみ助けられます。

他の人は、一般的に開発者に高速マシンを持たせたいと答えています。同意する。RAMをスキップしないでください-できるだけ多くのメモリを必要とする-一部のビルドプロセスはディスク使用量が非常に多くなります。

削除することを検討したいのは、ビルドドライブ上のウイルス対策です！それは減速するだけであり、非常に強力な減速要因になる可能性があります。

可能であれば、開発者がLinuxで開発できるようにすることもできます。そこにあるツールは、あらゆる種類の追加タスク（ファイル内の何かをgrepするなど）に対してはるかに優れています。これもアンチウイルスを取り除きます。

私の職場のMacbook Proは数年前のものです。LinuxとWindows（IEの癖をテストするため）vmsのほか、いくつかのWebブラウザーとターミナルが開いている間、OSXスピニングホイールがたくさん現れます。それが回転するときに私が何をするかを推測し、私は座って待つ。この場合、マシンが遅いと生産性が低下します。

多くのアプリケーションの問題は、開発者が実際のデータセットを「完了する」前にテストすることです。対話型アプリケーションの場合、ベースラインテストマシン/ VMが必要です。

私は低速のWindows95マシンで作業しており、ForthおよびJavaScriptでMindForth人工知能を効率的に記述できます。

プログラマに良いハードウェアを手に入れるべきかどうかをプログラマに尋ねるのは、太った男に食べ物が好きかどうかを尋ねるようなものです。これは主観的なやり取りであることは知っていますが、それでも...質問する価値はありますか？：P

もちろん、私は大多数の意見に賛成です：いいえ。