ハクソク

世界を動かす技術を、日本語で。

-2000行のコード

334日前原文(folklore.org)

概要

  • 1982年初頭、Lisaソフトウェアチームの進捗管理手法
  • コード行数 による生産性評価の導入
  • Bill Atkinson の反発と独自の最適化
  • Quickdraw の改良による大幅な効率化とコード削減
  • 結果として評価方法の見直しに至ったエピソード

コード行数マネジメントの問題点

  • 1982年、Lisaソフトウェアチームで 出荷に向けた追い込み が始まる
  • マネージャーが 各エンジニアの進捗を「週ごとのコード行数」で管理 する制度を導入
  • 毎週金曜日に コード行数を記入するフォーム の提出を義務化
  • Bill Atkinson （Quickdrawの開発者、UI設計の中心人物）はこの基準に疑問
  • 「効率的で小さく速いプログラムを書くこと」が本来の目的 であり、コード行数の多さはむしろ逆効果と指摘
  • コード行数重視は 冗長でバグの多い設計を助長 する危険性

Quickdraw最適化と-2000行

  • Atkinsonは Quickdrawの領域計算エンジンを全面的に再設計
  • 単純かつ汎用的なアルゴリズム で処理速度を約6倍に向上
  • 最適化の副産物として 約2,000行のコード削減 を実現
  • 初めてフォームを提出する際、 「-2000」と記入
  • マネージャーの反応は不明だが、 数週間後にはAtkinsonだけ提出不要に
  • 本人は この対応に満足

ソフトウェア生産性評価の本質

  • ソフトウェア開発の進捗や品質は単純な数値で測れない
  • イノベーションや最適化による「減らすこと」も価値
  • エンジニアの本質的な貢献 はコード量ではなく、 設計や効率化、品質向上
  • 管理手法の柔軟性・見直しの重要性

Hackerたちの意見

大学の時、ある会社で働いてたんだけど、その会社の目的は、管理技術を使って新入生たちに質の高いコードを書かせることだった。でも、全然できなかった。バグの原因になってるコードを見つけて修正しても、バグはまだ残ってたんだ。前の学生たちが、関数にパラメータを追加する代わりに、コピーを作ってちょっと修正してたから。あの秋には、彼らのコードベースの約4分の3（何千行ものTurbo Pascal）を削除したよ。ボーナスとして、顧客はエネルギー省で、そのプログラムは核物質の在庫管理をしてたんだ。おやすみ。

└

コピーを作ってちょっと修正する 既存のコードを壊さないだけじゃなくて、管理者の目には個人の貢献度を上げるっていうメリットもあるんだよね。あ、あと、元に戻すのもすごく簡単で、最新のコピーを見つけて削除するだけで済む。絶対うまくいくよ、約束する。

└

これ、ブラックスバーグでの出来事だったのかな？

└

一度、こういうことを習慣的にやる契約者たちと関わったことがあるんだけど、これが混乱を招く可能性があると指摘したら、「それがCtrl+Fの役割だよ」と言われた。

└

こういうコードの重複を習慣にしている人と一緒に働いているんだけど、通常は要求が厳しくて声が大きい人のために、何かを急いで作るための努力なんだ。共有関数をリファクタリングしてエッジケースに対応させるのは時間とテストがかかるから、彼はやらない。これが根本的な問題の症状なんだよね。

関連情報。他にも？ ネガティブ2000行のコード (1982) - https://news.ycombinator.com/item?id=33483165 - 2022年11月 (167コメント) -2000行のコード - https://news.ycombinator.com/item?id=26387179 - 2021年3月 (256コメント) -2000行のコード - https://news.ycombinator.com/item?id=10734815 - 2015年12月 (131コメント) -2000行のコード - https://news.ycombinator.com/item?id=7516671 - 2014年4月 (139コメント) -2000行のコード - https://news.ycombinator.com/item?id=4040082 - 2012年5月 (34コメント) -2000行のコード - https://news.ycombinator.com/item?id=1545452 - 2010年7月 (50コメント) -2000行のコード - https://news.ycombinator.com/item?id=1114223 - 2010年2月 (39コメント) -2000行のコード（メトリクス＝悪） (1982) - https://news.ycombinator.com/item?id=1069066 - 2010年1月 (2コメント) ちなみに、気になる人へ：再投稿は1年くらい経てばOKだよ（https://news.ycombinator.com/newsfaq.html）。たまに古典を振り返るのも楽しいし（でもあんまり頻繁にはね）、新しい世代が初めてクラシックに出会う機会にもなるから、これもこのサイトの大事な機能だよね！

└

僕はシンプルな人間だから、-2k行のコードを見ると、アップボートする。これは、単一軸の指標で生産性を測ろうとしたクライアントに話したことがある。アトキンソンの事例が示すように、実際の生産性はユーティリティでしか測れないんだ。もしそれを正確に定量化できるなら、経済学のノーベル賞候補に入るかもしれないね。

開発者の生産性がどれだけ「向上した」かっていう統計を見るたびに、この話を思い出す。

└

今の業界のお気に入り、「私たちの新しいコードのX%はAIによって書かれています！」ってやつ。

└

新しい原子力発電所を建設・維持するコストを含めると、開発者の効率が途方もないことになるよ。

└

AIに厳しくしないで、コードを削除することもできるから！ https://forum.cursor.com/t/cursor-yolo-deleted-everything-in...

僕の最高のコミットの一つは、約6万行のコードを削除して、全ての状態をメモリに保持しなければならなかった「サーバー」を、約5千行の軽量なロジックに置き換えたことだよ（2000年代初頭の話）。それは純粋にアルゴリズム的な勝利で、特定のガイド付き部分グラフ同型性を見つけることができたんだ。ターゲットは木（単一のルートを持つ有向非循環グラフ）で、元の（一般的な）有向二部グラフを一度通過しながら、出力グラフ（木）に頂点と辺を出力し、現在の生成ステップに影響を与えることができる小さなスタックだけを維持してた。あの「-60,000行（またはそれに近い行数）」っていう巨大なコミットを今でも覚えてる。今までで最高のコミットだったな。あの頃は楽しかった。以来、アルゴリズム的に印象的なことはやってないけど。

└

面白そうだね。もっと詳しく書いたことある？

└

ソフトウェア製品は何をするものだったの？

└

サーバー全体をライブラリや実行可能ファイルに変えるのっていいよね。

ずいぶん前、私は大きなプロジェクトで働いていたんだけど、PLたちが見たこともないようなひどい指標を作り出したんだ。チーム全体に見えるように手書きの大きなリストを作って、各開発者が直したバグの数と引き起こしたバグの数をマークしてた。目を疑ったよ。私はそのチームの横で自分のプロジェクトをやってたから、なんとかこの災害からは逃れられたけど、知り合いの一人は運が悪かった。彼がこの有害なリストで苦しんでいるのを見たんだ。それで、最近聞いたデンマークの映画監督ラース・フォン・トリアーの話を彼にした。フォン・トリアーは、政府が責任を持つ重要なデンマークのアーティストの「カノン」リストに選ばれる予定だったんだけど、彼はデンマークの旗（赤に白い十字）を使って、白い線を切り取って再び縫い合わせ、赤い共産主義の旗を作る短編映画を作ったんだ。そしたら、フォン・トリアーはすぐに「ペルソナ・ノン・グラータ」にされて、「カノン」から外された。その日の後、友達がバグの修正・発生リストに近づいて、自分の行を切り取ってテープで貼り合わせ、再び壁に貼ったんだ。PLが後で部屋に入ってきて、リストをじっと見つめて、何が起こったのか気づくまで長い時間立っていたのを忘れられない。「これ、君がやったの？」とPLが友達に聞いた。「うん」と彼が答えた。「なんで？」とPL。「そのリストの一部になりたくないから」と彼が答えた。翌日、そのリストは消えていた。成功したサブバージョンの素敵な思い出だね。

└

フラグとリストの変更を視覚化するのがすごく難しいんだ。

昔のディルバートの漫画で、尖った髪のボスが製品のバグを直すたびに報酬を出すって宣言してた。ウォリーはデスクに戻りながら「今日はミニバンをコーディングするぞ！」ってつぶやいてた。

└

https://i.imgur.com/tyXXh1d.png マネージャーが休憩室の壁にそれを貼ってるよ。

└

すみません、ミニバンの話は何ですか？

今日、+0-2kLOCの変更をコミットしたんだけど、同僚の2ヶ月分の貢献を削除しなきゃならなかった。書き直さなきゃいけなかったからね。最高の気分だよ。

└

あのコードを追加したのは全然無駄じゃなかったよ。コードは、すべての行をロバのように働かせる必要はないんだ。コードは…考えることなんだ。

昔のオペレーションの仕事で、チケットタッチという指標があったんだ。ある同僚は、他の人のほぼ倍の数値を出してたけど、その指標だけだった。見てみたら、彼はチケットにメモを書くとき、全部を一度にコメントに入れるんじゃなくて、進めながら少しずつ書いてたんだ。どちらのやり方も間違ってはいなかったけど、彼のその統計が膨らんじゃったんだよね。

僕は、働いた2つの会社で追加したコードの行数がネットでマイナスなんだ。それを誇りに思ってるよ。