プログラミングはなぜ魅力的でありながら、苦痛を伴うのか？

今日、AIコーディングツールは前例のない速さでプログラミングの敷居を下げています。ますます多くの人々が自らの手で製品を構築し、根本的な問いを再訪しています。プログラミングとはどのような技術なのか？なぜこれほど魅力的であり、なぜこれほど難しいのか？フレデリック・P・ブルックス・ジュニアが50年前に『人月の神話』で書いた「ザ・タール・ピット」は、今日でも驚くほど関連性を持って読めます。ブルックスはIBMのSystem/360とそのオペレーティングシステムの開発を主導したことで最もよく知られています。彼は大規模ソフトウェアシステムの構築を、タールピットに閉じ込められた原始の獣に例えました。真の危険は単一の困難ではなく、無数の問題が同時に現れ、互いに絡み合うことでした。チームが苦闘すればするほど、時にはより深く沈んでいきました。プログラミングは苦痛でもあり、喜びでもあります。それは些細なことにあなたを mire させますが、同時にクリエイターにアイデアを現実にする力を与えます。タールピットを通り抜け、それでも創造の喜びを見つけられることを願っています。 ザ・タール・ピット 原始時代、最も鮮烈な光景の一つは、タールピットで死闘を繰り広げる巨大な獣たちの姿でした。恐竜、マンモス、サーベルタイガー...。自由になろうとすればするほど、タールはよりきつく彼らを掴みました。どんな獣も沈むのを避けるほど強力ではありませんでした。過去10年間、大規模システムプログラミングはタールピットでした。多くの強力なチームがその中で激しくもがきました。多くのチームが稼働するシステムを持って現れましたが、目標、スケジュール、予算を同時に満たせたチームはほとんどありませんでした。困難はどの側面にも固有のものではありません。どの問題も解決可能に見えます。単一の足がまだ引き抜けるようなものです。本当に恐ろしいのは、多くの要因が同時に現れ、互いに相互作用し、最終的にプロジェクト全体をますます深く引きずり込むことです。これを解決するには、まずプログラミング技術そのものと、その中に内在する喜びと苦悩を理解する必要があります。 プログラム、製品、システム 私たちはしばしば、改造されたガレージにいる2人のプログラマーが巨大企業のプログラムを凌駕したという話をニュースで読みます。すべてのプログラマーはこのような話を信じたいと思っています。なぜなら、単にプログラムを書くだけなら、私たちのスピードは組織の「年間1000行」のペースをはるかに超えていることを知っているからです。では、なぜ大企業の開発チームは、集中したガレージのデュオに取って代わられなかったのでしょうか？1976年、21歳のスティーブ・ジョブズと友人のスティーブ・ウォズニアックはガレージでApple Computerを設立しました。プログラムはそれ自体が完結しており、開発環境で作者が実行できるものです。これがガレージプロジェクトであり、プログラマーが自身の生産性を推定する際に暗黙的に参照するものです。しかし、プログラムが真に有用になるためには、2つの境界を越える必要があります。最初の境界は、プログラムから製品への境界です。作者だけがそれを実行できれば十分ではなくなります。誰でもそれを実行、テスト、修理、拡張できる必要があります。異なるオペレーティング環境で機能し、多様なデータを処理できる必要があります。一般的な製品になるためには、プログラムはより一般的な方法で記述される必要があります。特に、入力の範囲と形式は、基本的なアルゴリズムが合理的に許容する限り、一般化される必要があります。次に、プログラムは徹底的にテストされ、信頼できるようになる必要があります。これは、入力範囲と境界を探るための実質的なテストケースのセットを準備、実行、文書化することを意味します。最後に、誰でも使用、修理、拡張できるように、完全なドキュメントが必要です。経験上、製品は同じ機能を持つデバッグ済みのプログラムの少なくとも3倍のコストがかかります。2番目の境界は、プログラムからシステム内のコンポーネントへの境界です。システムは孤立したプログラムではなく、機能が調整され、形式が制約された相互作用するプログラムの集合です。システムコンポーネントになるためには、プログラムのすべての入力と出力は、定義されたインターフェース仕様に形式と意味で準拠する必要があります。また、事前に決定されたリソース予算（メモリスペース、I/Oデバイス、計算時間）に合わせて設計される必要があります。最後に、すべての予想される組み合わせで他のコンポーネントとテストされる必要があります。このテストは広範囲に行われる必要があります。なぜなら、テストケースの数は組み合わせ的に増加するからです。また、時間がかかります。各コンポーネントが個別にデバッグされていても、コンポーネント間の予期しない相互作用が微妙なバグを発生させる可能性があります。システムコンポーネントは、同じ機能を持つスタンドアロンプログラムの少なくとも3倍のコストがかかります。プログラムが製品であり、かつコンポーネントでもある場合、そのコストは単純なプログラムの9倍になります。しかし、これが真に有用な結果であり、ほとんどの開発努力の目標です。 クラフトの喜び なぜプログラミングは楽しいのでしょうか？第一に、物事を作り出す純粋な喜びがあります。子供がおもちゃの泥団子に喜ぶように、大人は物事を作ることを楽しみます。特に自分のデザインしたものを。この喜びは、神が創造することに喜びを感じたことのこだまであると私は思います。一つ一つの葉、一つ一つの雪の結晶はユニークで新鮮です。第二に、他者に役立つものを作る喜びです。心の奥底では、他者に私たちの仕事を使ってもらい、それが役立つと感じてほしいと願っています。この点において、プログラミングシステムは、子供が「お父さんのオフィス用」に作った最初の粘土のペン立てと変わりません。第三に、複雑なパズルのようなオブジェクトを作る魅力です。プログラムは、互いに噛み合う部品のパズルのようなものです。ルールとロジックがステップバイステップで展開されるにつれて、それらがサイクルで噛み合うのを見るのは魅力的です。適切にプログラムされたコンピュータは、複雑なピンボールマシンやジュークボックスのようなものです。ボタンを押すと、内部のメカニズムが作動し、結果が出てきます。ただし、プログラミングはこの魅力を極限まで高めます。ENIAC、世界初の汎用電子コンピュータの一つ。 第四に、常に学ぶことの喜びです。プログラミングタスクはめったに繰り返されず、問題は常に新しい方法で提示されます。ソルバーは常に何かを学びます。時には実用的、時には理論的、時にはその両方です。最後に、扱いやすい媒体で作業する喜びがあります。詩人のように、プログラマーは純粋な思考素材のみで作業します。彼は空中に城を築き、想像力だけで新しい世界を創造します。これほど柔軟で、磨き直し、再構築しやすく、壮大な概念的ビジョンを実現するのに適した創造的な媒体はほとんどありません。しかし、プログラムは詩人の言葉とは異なります。それはある意味で現実です。なぜなら、それは動き、機能し、現実世界に作用するからです。結果を印刷し、絵を描き、音を出し、機械的な腕を動かします。神話や伝説の魔法は、私たちの時代に現実のものとなりました。人々はキーボードに正しい呪文を入力し、画面が生き生きとして、存在しないものやありえないものを表示します。プログラミングは、私たちの奥深くに組み込まれた創造的な憧れを満たし、私たち全員が共有する感性に触れるため、楽しいのです。 クラフトの苦悩 もちろん、プログラミングは喜びばかりではありません。その内在する苦悩を理解することで、それらが来たときに乗り越えやすくなります。最初の苦悩は、完璧さの必要性です。コンピュータは、この点でも魔法に似ています。一文字の間違い、一箇所の配置ミスで、呪文は失敗します。人間は完璧さには慣れていません。それを要求する活動はほとんどありません。この完璧さの要件に適応することが、プログラミングを学ぶ上で最も難しい部分だと私は思います。2番目の苦悩は、責任が権限を超えることが多いということです。目標は他者によって設定され、情報とリソースは他者によって提供されます。プログラマーは、自分の作業条件を制御することはめったになく、時には目標さえも制御できません。管理用語では、「権限は責任に見合わない」となります。しかし、これはすべての分野に当てはまるようです。物事を成し遂げる真の仕事には、その責任に見合う正式な権限が伴うことはほとんどありません。実際には、真の権限は肩書きからではなく、一貫して結果を出すことによって構築された影響力から生まれます。VisiCalc、1979年に発売された世界初の商業的に成功したスタンドアロンソフトウェアであり、初の電子スプレッドシートです。多くのプログラマーにとって、特別な苦悩があります。それは、他者のプログラムに依存することです。これらはしばしば設計が悪く、 crudely 実装され、不完全に提供されます。ソースコードなし、テストケースなし、ドキュメントが不十分です。そのため、彼は...