サンプルサイズがプロジェクトの長さに影響しないことを説明する方法
大規模なエンタープライズプロジェクトがあり、通常、ソースデータベースから宛先データベースにデータをコピーしてから、このデータを同期するいくつかの追加アプリケーションを設定します。
最後のプロジェクトには250,000項目（データ行）が含まれていました。次のプロジェクトには、4,000アイテムのみが含まれます。プロジェクトマネージャー/ビジネス関係者は、プロジェクトは最後のプロジェクトのサイズのほんの一部であるため、プロジェクトの完了時間は1/10であると信じています。
何が良いのかanalogyあるシステムから別のシステムにデータを転送するコードを書くことは、アイテムの数に関係なく同じ量がかかることを説明するために使用できます。プログラミングの観点から同じ時間。
国の遠隔地への新しい4車線の高速道路を建設するようなものだと伝えてください。その道路が1日あたり100台の車で使用される場合でも、1日あたり1000台の車で使用される場合でも、道路を作成するための労力はほぼ同じです。
確かに、1日に100万台の車をサポートする場合は、道路をもう少し頑丈にする必要がありますが、それでも、同じ木を切り倒し、同じ山を爆破し、同じ量を平準化する必要があります汚れの量、およびこれらの活動は、道路を使用する車の数に関係なく、ほぼ固定費です。
計算機を渡して、1238783423から9858238483を追加するように依頼します。次に3423に8483を追加するように依頼し、約100,000時間早く回答を期待できることを伝えます。
また、データ量が（おそらく）ソフトウェアが開発時間ではなくrunにかかる時間の長さに影響を与えることについて説明することもできます。
それをマネージャーに伝えてください。
毎秒1ウィジェットでウィジェットを作成するマシンを構築する場合、それを使用して100ウィジェットまたは10000ウィジェットを作成するかどうかは問題ではなく、マシン自体の構築にも同じ時間がかかります。
違いはビルド時ではなく実行時です。
すべての管理クラスは、架空のウィジェットファクトリでこのような問題に対処します。
類推を使用しないでください。説明してください。
- 非常に少数のアイテム（10？）の場合、手動で変換するのが最も安価です。プログラムをまったく書かないでください。
- アイテムの数が少ない場合（100？）、プログラムを作成する価値があります。理論的には可能なデータの順列を無視することで節約できる可能性がありますが、実際には小さなデータセットでは表示されません。または、プログラムがそれらを拒否できるほど小さい数で表示され、手動で変換できます。データで簡単な分析を実行して、コーナーケースが実際にデータに表示されているかどうかを確認することができます。表示されない場合は、無視してかまいません。
- この時点を過ぎると、データの実際のサイズは影響を受けません。あらゆる入力を処理できる深刻なプログラムを作成する必要があります。プログラムは1,000アイテムまたは100,000を処理できます。実行に時間がかかるだけです。
教育は話すよりも優れています:)
たとえ類推ではありませんが、私はこの議論に対処するための良い方法を信じています：それに致命的な欠陥があることを示してください。
以前のプロジェクトには、（私が得たものから）いくつかの変更を加えたデータのコピーが含まれていました。
私が正しく理解していれば、それは、たとえば100人の会計士のチームが数か月でできることです。では、なぜ彼らはソフトウェア開発者を問題に投げ込んだのでしょうか？
作成したソフトウェアは、1,000万個のデータを処理するか1000万個のデータを処理するかを気にしません（正確ではありませんが、マネージャが気にかけているのではないかと思いますO(n)複雑さ）。したがって、それはおそらくより安く、より速く、よりクリーンでした（エラーが発生しにくいプロセス）。
さらに急進的である場合、ソフトウェアチームの作業速度が気に入らない場合は、いつでも会計士を呼んで手作業で作業するよう提案することもできます。
これにより、最後のプロジェクトの開発中にマネージャーの生活がはるかに楽になり、次のソフトウェアを理解するために同じロジックを適用する必要があるときに、1千万でも4でも機能するかどうかは気になりません。 000行、彼らは突然それを忘れます。
あなたの場合、マネージャーは単に 推定ゲーム をプレイしており、4000と250000の違いを指摘し、何らかの「罪悪感」を期待することで、チームをより速く働かせようとしていると思います。私は間違っている可能性がありますが、これが以前に行われたのを見たことがあります。
これは、プログラマーのチーム（実際にはあらゆるタイプのクリエイティブチーム）を管理するためのひどい方法であり、誰の助けにもなりません。
あなたがアナロジーを求めたのは知っていますが、それは間違ったテクニックだと思います。
他の人が言及したように、データサイズは実行時間ではなくに影響することを強調する必要があると思いますビルド時間。
だから、彼らのためにそれを分解します-あなたは実際にtwoサブプロジェクトを構築し、実行しています。構築プロジェクトは、（ほとんどの場合）実行するデータの量とは無関係である必要があります。問題となるのは、データのtypesだけです。
ランタイムに関しては、確かに、データサイズに応じてそれを因数分解できます（重要な固定オーバーヘッドを除きます）。
メルボルンまで車で行かなければならないようなものですが、最初に車を組み立てる必要があります。
確かに、シドニーまでの運転はもっと速いかもしれませんが、車両の組み立てには同じ時間がかかります。
さて、私はあなたにすべての類推を与えました。
たぶん電話？あなたの顧客はカスタムメイドの電話を望んでいます。彼が1日あたり0コールまたは1日あたり100コールを発信する場合、自分の電話を作成するのと同じ時間がかかります。
電話が送信するデータは、プログラムによってコピーされたデータに類似しています。
あなたのマネージャーは、開発時間とプログラムの実際の実行時間を混同しているようです。しかし、彼らの誤解は異なるかもしれません。彼らは、関与する「フィールド」が少ないと想定するかもしれません。データレコードが少なくなるだけではありません。 10万個の個別のデータフィールドがある場合、10個のフィールドだけと比較すると、大規模な開発作業になります。システムからシステムへのより多くのマッピング作業。この場合、実際には正しいかもしれませんが、依然として一定のオーバーヘッドがあり、時間を取得するために単純にフィールド数で除算することはできません。
私がそれを説明したいので、データは2次元の長さと幅を持っています。長さはレコード数、幅はすべてのテーブルの列の総数です
これで、データをインポートしたいとき、それは穴からブロックを取得するようなものです。最小の寸法に十分な大きさの穴を開けてから、ブロックを通過させる必要があります
現在、1000万と1万の最小の寸法は幅です。したがって、穴を開けるのにかかる時間を決定するのは幅です。
メタファーを完成させるために、手動でデータを入力するよりも短い長さである場合