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

-2000行のコード

2025年6月26日原文(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行(またはそれに近い行数)」っていう巨大なコミットを今でも覚えてる。今までで最高のコミットだったな。あの頃は楽しかった。以来、アルゴリズム的に印象的なことはやってないけど。

Hacker Newsで議論の続きを見る