ITの世界からの奇妙な倒錯

Daily WTFの Webサイトでは、14年にわたってITの世界からおもしろくてワイルドで悲しい物語を収集しています。 私は面白いと思われるいくつかの物語を翻訳しました。 すべての会社名と名前が変更されました。

3,000マイルで働くには

著者のスヌーフルの個人的な経験からの実話。 [オリジナル]

何十年も前、防衛請負業者DefCon Incは米国陸軍に勤務し、戦闘で使用される何らかのアプリケーションを作成するための新しい契約を取得しようとしました。 同社は、このプロジェクトを実行するのに十分なスタッフがいることを提案で示したかった。 そのため、彼女は千人以上の多様なプログラマー、プロジェクトマネージャー、マネージャーなどを雇いました。 軍隊は、さまざまな商業的申し出を研究しましたが、必要なプロセス、手順、要件に完全になじみのない多数の新入社員を見て、彼らは契約を別の会社に移しました。 請負業者は、彼のために、この千人全員を解雇しました。

数ヶ月後、別の同様の契約が発生しました。 同社は再び1000人を雇用し、スタッフがいることを示しました。 数ヶ月後、契約は再び別の請負業者に移され、会社は再び千人全員を解雇しました。


2年の間に、これは数回繰り返されました。

結局、採用可能なスタッフの大部分は、会社の非常に短い採用解雇サイクルを既に認識していたため、請負業者は、教育機関を卒業したばかりの新人以外の人を引き付けることができませんでした。 最後に、一部のトップレベルのマネージャーは、デスクのおかげでこれらのすべての人々が会社のスタッフの経験豊富な開発者よりもはるかに安価であり、会社が雇った人々が契約のために解雇したという事実に感銘を受けました。 そのため、彼は会社のすべての経験豊富なスタッフを安価な若い従業員に置き換えるように命令しました 。 このプロセスには2年かかりましたが、それでも起こりました。

給与コストが大幅に低下し、経験豊富な開発者候補者全員を怒らせたため、会社は給与予算を増額することなく常勤スタッフを増やすことができました。 彼女は若い、経験の浅い開発者しか最終的に契約を結ぶことができなかった。

残念ながら、これらすべての若い開発者には経験がほとんどなく、会社にはもはや彼らを訓練できる人がいませんでした。 したがって、2年間の契約の結果は、この信頼性の低いプロジェクトであり、しばしばクラッシュし、予測できない動作をし、修正できませんでした。 このようなプロパティは、起動および爆発する必要があるシステムを扱う場合には望ましくありません。

ある時点で、幹部の1人が何が起こったかを理解し、会社が中国の店で象のように振る舞うのをやめ、高給のコンサルタントを雇わなければならなくなりました。 残念ながら、高給コンサルタントは雇用サイクルをよく覚えており、組織とは何の関係も持ちたくありませんでした。 しばらくして、会社は雇用条件を大幅に改善する必要があり、最終的に数人の経験豊富な従業員が正社員として仕事に就くことに同意しました。 ニュージャージー州で起こった。

経営陣がプロジェクトにこれらの新しい従業員を任命して作業を促進した後、新しい従業員は「ちょっと待ってください。このプロジェクトの途中に大きな穴があります！」と経営陣は、プロジェクトのこの部分は分類されており、機密情報であり、カリフォルニアの企業でのみ。 適切な承認が要求され、取得された後、経験豊富な従業員がカリフォルニアの施設に2週間送られました。

旅行に同意する前に、開発者は勉強した後、どのように資料にアクセスできるかを知りたがっていました。 結局のところ、アクセスはカリフォルニアのその場でのみ可能であり、すべての従業員はニュージャージーに住んで働いています。 彼らはカリフォルニアで詳細を学ぶと言われました。

さて、彼らは全員西海岸に飛んでホテルにチェックインし、オフィスに向かいました。

その瞬間、彼らは対処する必要があるすべての問題について知らされました。 作業の第2週の木曜日に、必要なすべてのアップグレードを完了するために約2年間の作業が必要であることが決定されました。 開発者は再び尋ねました： 「ニュージャージーから材料にアクセスするにはどうすればいいですか？」マネージャーは、すべての作業は現場で行われるべきであり、今後2年間はカリフォルニアに残ると答えました。 来週の月曜日から。

しかし、待ってください、彼らはこれを家族と話し合う機会がありませんでした！ 親の1人が90％の時間を欠くことは、子供にどのように影響しますか？ 彼らは2年間ホテルや空港に住みたいですか？ なぜ地獄は、カリフォルニア州ではなくニュージャージー州で従業員を雇わなかったのですか？

請負業者はニュージャージーにあるため、彼が雇うスタッフもそこに登録しなければならないことがわかりました。 もちろん、これが雇用前に報告されていた場合、ほとんどの従業員（全員ではないにしても）は働くことを拒否したでしょう。 彼らが知っていれば、誰も飛行機に乗ってカリフォルニアに飛んでプロジェクトに慣れることはありませんでした。

マネージャーの残りの仕事が会社の犠牲者の必要性に擦り付けられたとは言えず、開発者は次のように自問しました。 金曜日の朝、すべての従業員は辞めて空港に戻り、帰宅しました。

軍の代表者は尊厳を持って振る舞い、人々が2年間家や家族を離れたくないという事実に共感しました。 しかし、請負業者と話したり、職場で経験豊富なスタッフを持つという彼の約束を果たすことになると、彼らははるかに厳しくなりました。

その結果、請負業者との契約は終了し、新しい契約を置き換えるために雇われました。

故障事例

[オリジナル]


新しい仕事の初日、 セバスチャンは特に熱心ではなかった。 彼はすでに多くを見て、無関心と悲観論を獲得しました。 この新しい作業に違いはありませんでした。多くの迷惑な同僚、考え抜かれた要件、古いコードベース、スパゲッティコードがいっぱいです。 しかし、彼女はうまく支払いました、そして、彼は彼の古いグループに疲れていました、彼は同じ馴染みのある顔に疲れていました。 したがって、彼は同じオフィスの政治と退屈な仕事のわずかに新しい色合いのために内部的に準備しました。

彼は、資格情報を求めてIT部門に行って、古いPackard Bellサーバーのうなり音とクリック音を聞いたとき、特に怒っていませんでした。 セバスチャンは、稼働中のコンピューターの要件を単にいくつかのレベルに下げ、新しいオフィスに戻りました。 はい、彼の立場は彼自身のオフィスとそれに対応する支払いを意味しました。 このために、彼は他の多くの事柄と妥協することができました。

彼のログインは最初の試行で機能しましたが、これは嬉しい驚きでした。 彼はWindows XPを期待していました。 Vistaが起動したとき、彼は新しいOSを喜ぶべきなのか、それともVistaであることに恐怖を感じるべきなのか確信がありませんでした。 管理者特権を完了し、UACをトリミングすることで、彼はしばらくの間、それが「7」であるふりをすることができました。 「私を怖がらせるにはもっと何かが必要です」と彼は考え、Outlookを開始しました。

受信トレイにはすでにメールがありました。新入社員向けの情報を含むいくつかのウェルカムレターと、マネージャーからの最初のタスクです。 控えめに言っても、タスクの割り当ての効率性に感銘を受け、彼は新しいリーダーからの手紙を開きました。

最初の手紙はこのようなものでした：

こんにちは、セバスチャン、完璧に研ぎ澄まされた職場環境へようこそ。 すべてが正しく行われます。 プロジェクトドキュメントを作成するときは、Bonk-Word（IBMのWebベースのドキュメント作成アプリケーション）を使用します。 頻繁に作業を保存することを忘れないでください！ Bonk-Wordがクラッシュした場合、再起動するにはIT部門に手紙を書く必要があります。

会社は設計文書を作成します。 すべてを受動的な声で書き、章の見出しを示すために紫を使用し、セクションの見出しを示すために緑を使用します。 文書は午前9時に会社の社長によって毎日チェックされるため、このために準備してください。 ヘッダーの間違いは、個人ファイルの黒いマークになります。

4年間解決できなかったMacintoshフォントの問題の解決策を設計することから始めます。 明日の午前9時までには、6ページの既製のプロジェクトドキュメントが必要です。 ありがとう

「明日は6ページ？」セバスチャンは心配した。 「効率が早すぎたのは嬉しかったと思います。 まあ、少なくとも退屈することはないだろう 」と彼は指を割って、Bonk-Wordを開き、いわゆるフォントの問題に対処し始めました。

彼が最初に知ったのは、マネージャーが頻繁に貯蓄について冗談を言っていなかったことです。 一日の終わりまでに、彼は精神的に賭けました：最初に落ちるもの-Bonk-WordまたはVista自体。 両方とも約30分ごとにクラッシュしました。 しかし、セバスチャンは、何らかの理由で、出発の統計を紙に記録することで安心した。 それは彼に思い出させた：他の何かが世界で働いていた。 最も単純な数学的操作は印象的ではありませんでしたが、信頼性がありました。 レギュラー。 安定。

おそらく、セバスチャンはこのオフィスで孤独を感じていたのでしょう。 しかし、彼は静かで別れていました。 絶え間ない出撃は迷惑だったが、セバスチャンはまだ前進した。 彼は、Postscript仕様、その使用方法に関する付属資料、World Wide Webの情報センターなど、フォントレンダリングに関するさまざまな文献を研究するために仕事で長続きしました。 。 彼はこのドキュメントで「各キャラクターをレンダリングするPythonプログラムを作成する」と広範囲に説明しました。 彼は一言で言うことができることを説明する2ページを費やしました。

「6ページ必要な場合、6ページになります」とセバスチャンは考えました。

初日は奇妙なことが判明しましたが、セバスチャンは少なくとも数年間は耐えられると思っていました。 彼は仕事を終え、建物を去り（古い革の下着の匂いがする）、ゆっくりと彼の「無料駐車スペース」（彼の目にはこの仕事を正当化するもう一つの利点）に歩いた。 ゆっくり-駐車場は錆によって完全に腐食し、多くの場所でコンクリートが完全に落ち、床と柱の補強材が露出したためです。

翌朝、正確に9:00に、セバスチャンは彼のマネージャーのオフィスにいて、電話で電話をかけた会社の社長からのプロジェクトの最初の検証を待っていました。 セバスチャンは、会社に60人の従業員がいることを考えると、社長との直接の会話に不快感を覚えたが、彼はそれに耐えなければならなかった。

「要求通りに、適切な量でやった。 ほとんどの場合、これは単なる形式的なものであり、その後は仕事に取りかかることができます。」

1時間後、屈辱と疲れ果てたセバスチャンは彼のオフィスに戻った。 彼が受け取った不条理だが残酷な批判は、彼の耳にまだ響き渡っていた。 社長によると、彼のセクションの見出しは「緑がかった」ものではなく、会社が要求したような緑ではなく、章の見出しは予想された紫ではなく「赤みがかった」ものでした。 さらに、彼はPythonを使用してフォントをデバッグすることは「不可能」であると明示的に言われました。 代わりに、セバスチャンはC ++で動作し、会社の「素晴らしい」ソフトウェアライブラリを使用するように命じられました。 社長の電話を待って、セバスチャンのマネージャーは文書を賞賛しましたが、チェック中に言葉を言わず、不可解に彼の机のレンガの壁を見ました。

セバスチャンはオフィスのドアを閉め、会社の残りの部分から遮断した。 彼は豪華な革張りの椅子に座って、ほとんど動作しないコンピューターの画面を見つめました。 彼はドキュメントを再度開き、Vistaが飛び出すことにしたので、マシンを再起動しました。 コンピューターが再び起動したとき、彼は銀行口座を確認し、住宅ローンの支払いについて考え、歯を磨きました。

「じゃあ」彼は空っぽのオフィスで大声で言った。 「これらのライブラリを見てください。」

彼が最初に探し始めたのはドキュメントでした。 当然、ドキュメントに夢中になっている会社では、「すばらしい」ライブラリのドキュメントは、正しい章見出しとセクション名で、理想的に正確な色合いの正しいフォントで正確に入力する必要があります。 しかし、ドキュメントは...ではありませんでした。 完璧な緑と紫の色のデザイン文書がたくさんありました。 しかし、彼らはライブラリ開発の方法論のみを説明し、その使用については何も言わなかった。

「気がおかしいのか？」セバスチャンは、車が3回目に再起動したときに自問しました。 「おそらく、コードは自己文書化されています...」

彼は恐怖を経験しましたが、驚きはあまりありませんでした。ライブラリは、標準ライブラリのストリング関数のよく考えられていないラッパーで構成されていました。

絶え間ない大失敗にもかかわらず、セバスチャンは打撃を保持しました。 彼は口頭脅迫の別のラウンドのために毎日召喚されました。 4年間、このフォントの問題に対処できませんでした。 それにもかかわらず、彼が提案したものはどれも大統領に合わなかった。 セバスチャンは会社の自分のライブラリを放棄し、有名なPythonの問題を解決し始めました。 最後に、彼らがまだ腐敗を広げているのなら、なぜ彼らはあなたに言うことをするのですか？ しかし、彼が使用したものは何でも：Pythonの彼自身のテスター、またはMicrosoft、Apple、またはAdobeのテスター-フォントは完全な混乱のままでした。 488根絶不可能、手に負えない、デザインパッチエラーによって解決できない。

大統領は、真実を認めることを断固として拒否した。 彼は、セバスチャンのせいだと主張しました。優れたC ++ライブラリを使用しなかったからです。

セバスチャンは、すべての選択肢を使い果たしたため、マネージャーの机の錆びたガレージの鍵と辞表を残しました。 彼は彼の甘いオフィスと彼らがコンピューターとして配った地獄のタイプライターに別れを告げた。 彼は最後に深呼吸をして、ひどい皮膚の臭いを感じて、ついに取り返しのつかないほど去りました。

何らかの理由で、彼は会社を見逃すことを疑っていました。

この種のヘルスケアで病気になる可能性があります

[オリジナル]

どの業界でも、互換性のないシステム間で転送する必要がある情報があります。 義人の生活を送っていたなら、これらのシステムは同じプラットフォーム上の異なるアプリケーションにすぎませんでした。 ただし、適切なパスから逸脱した場合、これらのシステムは、異なるバイト順序の異なるオペレーティングシステムで動作する異なるプラットフォーム用に異なる言語で記述されています。 Mac OSの一部のバージョンのSafariの一部のJavaアプリケーションを想像してください。Windowsの一部のバージョンの.NETの一部のバージョンと通信する必要があり、次にCOBOLの一部のバージョンと通信する必要があります。メインフレームで実行されるバイナリEBCIDIC 。

誰もがそのような悪夢を想像することができるずっと前に、私たちはSGMLと協力しました.SGMLは劣化し、 XML に進化しましたDTDおよび/または検証および構文解析スキーム以外は何も知らない。

最善を期待せずに 、作業を簡素化するために、XMLラッパーライブラリの上に書きました。

残念ながら、彼らはその仕事に対処しませんでした。


医療業界では、一部のコペンソースの人が（H）ealthcare（API）プロジェクト、またはHAPIを作成しました。これは、本質的に医療業界向けのオブジェクト指向のテキストメッセージングパーサーです。 残念ながら、彼らは「いつ止めるべきかわからない」症候群に苦しんでいるようでした 。

区切り文字列または固定形式文字列をテキストフィールド値のリストに単純に分割する汎用パーサーを実装する代わりに、 最新バージョンでは、それぞれ独自の高レベルデータ構造を持つ1205種類のパーサーを実装しています。 最高レベルの構造には、多数の下位構造があります。 各パーサーには、フィールドごとに1つ以上のアクセス方法があります。 フィールドは、単一のインスタンスまたはインスタンスのリストにすることができます。その場合、使用するアクセス方法をプログラムで決定する必要があります。

これは、約15,000のメソッド呼び出しを持つAPIです！ これらの開発者は何を考えていましたか？

たとえば、クラスEHC_E15_PAYMENT_REMITTANCE_DETAIL_INFOには、0個以上の製品サービスセクションが含まれる場合があります。 だから私はすぐにある種の配列やリストについて考え始めました。 したがって、このようなものの代わりに：

  EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO情報= ...;
    リスト<EHC_E15_PRODUCT_SERVICE_SECTION> prodServices = info.getProductServices（）;
     //繰り返します

...次のいずれかを実行する必要があります。

  //下部構造を取得します
     EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO情報= ...;
	
     //下位構造から組み込みの製品サービスを取得します

     // ...メッセージが1つしかないことが確実にわかっている場合：
     EHC_E15_PRODUCT_SERVICE_SECTION prodSvc = info.getPRODUCT_SERVICE_SECTION（）;
	
     // ...いくつあるかわからない場合：
     int n = infos.getPRODUCT_SERVICE_SECTIONReps（）;
     for（int i = 0; i <n; i ++）{
         EHC_E15_PRODUCT_SERVICE_SECTION prodSvc = info.getPRODUCT_SERVICE_SECTION（i）;
         //これを使用します
     }

     // ...または、それらを取得して反復することができます
    リスト<EHC_E15_PRODUCT_SERVICE_SECTION> allSvcs = info.getPRODUCT_SERVICE_SECTIONAll（）; 

...そして、目的のメソッドを呼び出す必要があります。そうしないと、例外が発生する危険があります。 ただし、APIを介して1つのタスクを実行する方法が多数ある場合、APIを使用してコードでタスクを実行する方法は多数あり、必然的に問題が発生します。

あなたは言うことができます： 「さあ、すべてがそれほど悪くない」 ; 必要なものだけを使用してください。 しかし、これらのデータ構造の一部は10レベル以上の深さに埋め込まれており、それぞれに数十のサブ構造やフィールドがあり、それらすべてにいくつかのアクセス方法があることがわかります。 さらに、それらはすべて本当に長い名前を持っています。 そして、HAPI開発者はタイピングにうんざりしており、略語としてLA1、ILT、PCRなどのデータ構造の使用を開始したことに気づきます。

APIは便利になろうとします：解析を要求しているフィールドで予期されるものが見つからない場合、例外をスローし、自分で何がうまくいかなかったかを把握する必要があります。 もちろん、これは、データストリームで何が送信されているかを既に知っていることを意味します。

匿名はヘルスケアで働き、HAPIにラップされたライブラリをサポートしました。 彼は、1つの追加フィールドを単純に解析することで、タスクを完了するために定期的に（数週間かかった）タスクを与えられました。 APIドキュメントのボリュームをじっくりと時間をかけて、彼はインターフェイス全体の代わりとして、いくつかのsplit、substring、parseDate、parseIntを含む300行の1つのクラスから共通のパーサーを作成しました。

その後、新しいフィールドの追加には10分しかかかりませんでした。