サンプルサイズがプロジェクトの長さに影響しないことを説明する方法

通常、ソースデータベースから宛先データベースにデータをコピーし、このデータなどを同期する追加のアプリケーションをセットアップする大規模なエンタープライズプロジェクトがあります。

最後のプロジェクトには250,000のアイテム（データの行）が含まれていました。次のプロジェクトには、4,000アイテムのみが含まれます。プロジェクトマネージャー/ビジネスパーソンは、プロジェクトは最後のプロジェクトのほんの数分の1のサイズであるため、プロジェクトが完了するまでの時間の1/10であるべきだと考えています。

あるシステムから別のシステムにデータを転送するコードを書くことは、アイテムの数に関係なく同じ量を要することを説明するために使用できる良い類推です-1アイテムまたは100,000,000のためにそれを書くことは、プログラミングからほぼ同じ量の時間がかかります視点。

国の遠隔地に新しい4車線の高速道路を建設するようなものだと伝えます。その道路が1日100台、1日1000台の車で使用される場合でも、道路を作成する労力はほぼ同じです。

確かに、1日あたり1,000,000台の車をサポートする場合は、道路をもう少し頑丈にする必要がありますが、それにもかかわらず、同じ木を切り倒し、同じ山を爆破し、同じ量を平らにする必要がありますどれだけ多くの車が道路を使用しても、これらの活動はほぼ固定費です。

計算機を提供し、1238783423を9858238483に追加するよう依頼します。所要時間を計ります。次に、8423に3423を追加するように依頼し、回答が約100000倍速くなると期待していることを伝えます。

また、開発時間ではなく、ソフトウェアの実行にかかる時間の長さに対するデータの量（おそらく）の影響を説明することもできます。

それをマネージャーに話します。

1秒間に1ウィジェットでウィジェットを作成するマシンを構築する場合、それを使用して100ウィジェットまたは10000ウィジェットを作成するかどうかは関係ありません。マシン自体も構築に同じ時間がかかります。

違いは実行時であり、ビルド時ではありません。

すべての管理クラスは、仮想ウィジェットファクトリを使用してこのような問題に対処します。

類推を使用しないでください。説明してください。

• 非常に少数のアイテム（10？）の場合、手動で変換するのが最も安価です。プログラムをまったく書かないでください。
• 少数のアイテム（100？）では、プログラムを作成する価値があります。理論的には可能なデータの順列を無視することで節約できますが、実際には小さなデータセットには表示されません。または、プログラムがそれらを拒否できるような小さな数字で表示され、手動で変換できます。コーナーケースが実際にデータに現れるかどうかを確認するために、データをすばやく分析することが可能です。表示されない場合、無視できます。
• このポイントを超えると、データの実際のサイズは影響しません。可能な入力を処理できる本格的なプログラムを作成する必要があります。このプログラムは1,000アイテムまたは100,000アイテムを処理できます。実行に時間がかかるだけです。

話をするよりも教育の方が良い:)

本当のアナロジーではありませんが、私はまだこの議論に対処する良い方法を信じています：それに致命的な欠陥があることを示してください。

あなたの以前のプロジェクトには、（私が得たものから）それにいくつかの修正を加えたデータのコピーが含まれていました。

私が正しければ、それは、たとえば100人の会計士のチームが数か月のうちにできることです。それから、なぜソフトウェア開発者を問題に投げかけたのですか？

あなたが作成したソフトウェアは、それが1000万個または1000万個のデータを処理するかどうかを気にしません（正確ではありませんが、私はあなたのマネージャーがO(n)複雑さを気にかけているとは思いません）。したがって、おそらく安価で、高速で、クリーンでした（エラーが発生しやすいプロセス）。

もっと過激な場合は、ソフトウェアチームの作業速度が気に入らない場合は、いつでも会計士を呼んで手作業で作業するよう提案することもできます。

これにより、最後のプロジェクトを開発している間、マネージャーの生活がずっと楽になりました。そして、次のソフトウェアを見つけるために同じロジックを適用しなければならないとき、それが1,000万または4 000行、彼らは突然それを忘れます。

あなたの場合、マネージャーは4000と250000の違いを指摘し、いくらかの「罪悪感」を期待して、単に推定ゲームをプレイし、チームをより速く働かせようとしていると思います。私は間違っている可能性がありますが、これは以前に見たことがあります。

これは、プログラマーのチーム（実際にはあらゆるタイプのクリエイティブチーム）を管理するためのひどい方法であり、誰にも役に立たない。

アナロジーを求めたのは知っていますが、それは間違ったテクニックだと思います。

他の人がパスで言及したように、データサイズはビルド時間ではなく実行時間に影響することを強調する必要があると思います。 だから、彼らのためにそれを分解-あなたは実際に2つのサブプロジェクト、ビルドと実行を持っています。（ほとんどの場合）構築プロジェクトは、実行するデータの量とは無関係である必要があり、データの種類のみが重要です。 ランタイムに関しては、確かに、データサイズに応じてファクターを設定できます（重要な固定オーバーヘッドを除きます）。

メルボルンまで車で行かなければならないようなものですが、最初に車を作る必要があります。
確かに、シドニーへの運転は速いかもしれませんが、車両の構築には同じ時間がかかります。
_{さて、私はあなたに類推を与えました。}

たぶん電話？顧客はカスタムメイドの電話を望んでいます。彼が1日に0コールまたは1日に100コールを発信する場合、電話を作成するのに同じ時間がかかります。

電話機が送信するデータは、プログラムによってコピーされたデータに似ています。

マネージャーは、開発時間とプログラムの実際の実行時間を混同しているようです。しかし、彼らの誤解は異なる場合があります。彼らは、関与する「フィールド」が少ないと仮定するかもしれません。少ないデータレコードだけではありません。個別のデータフィールドが100000個ある場合、10個のフィールドのみに比べて大規模な開発努力が必要になります。システムからシステムへのより多くのマッピング作業。この場合、実際には正しい可能性がありますが、依然として一定のオーバーヘッドが伴うため、時間を取得するためにフィールドの数で単純に割ることはできません。

説明したいように、データには長さと幅の2つの次元があります。長さはレコード数、幅はすべてのテーブルの列の総数です

これで、データをインポートするときは、穴にブロックを通すようなものです。最小寸法に十分な大きさの穴を開けてから、ブロックを通過させる必要があります

現在、1000万と1万の最小寸法はまだ幅です。そのため、穴を開けるのにかかる時間を決定するのは幅です。

メタファーを完成させるために、ffは、データを手動で入力するより短い長さです

毎週数百のクライアントファイルをインポートしています。

私が見つけた1つのことは、小さなファイルは一般的にデータインポートの開発に時間がかかることです：

• 彼らはルールに従う可能性が低いです（標準のファイル構造を持っているので、小さなクライアントが私たちが要求する標準形式でデータを提供するのを見たことはありませんが、大きなクライアントはそれが重要である理由を理解しています）
• 特に、すでにデータ整合性ルールが組み込まれているデータベース（大規模ファイルが由来する傾向がある）ではなく、Excelファイルから由来する場合、データ整合性の問題がより多く発生する傾向があります。
• 毎回同じ形式で提供される可能性は低くなります。

標準の子プロセスを備えた親子SSISパッケージを構築することにより、開発の時間を大幅に節約でき、標準の形式でデータを取得するために必要な操作を親で実行できることがわかりました。そうすることで、見積りを行う際のレコード数の問題ではなく、取得するファイルが標準にどれだけ近いかという問題になります。小規模なものは標準に適合しないため、開発に時間がかかる場合、それほど多くの苦情を受けません。

プログラムを書くことは、新しい従業員を雇うようなものです。あなたは彼らにデータを見つける場所、それをどうするか、そしてあなたに結果を与える方法を教える必要があります。彼らがそれを正しくしていることを確認するために、しばらく彼らに目を光らせておく必要があります。彼らが複雑で重要な仕事をしている場合、または非常に多くの仕事をしようとする場合、訓練には少し時間がかかるかもしれませんが、何であれかなりの時間がかかります。

多くのマネージャーは、新入社員のトレーニングに伴うオーバーヘッドに精通しているため、これは理にかなっているかもしれません。

（あなたの新しい従業員がどれだけ多くのレコードを投げても些細な時間で仕事を終わらせることができる超強力なロボットである限り、類推は崩れますが、うまくいけば、それまでにあなたがあなたのポイントを作ったことを願っています。）