『Can’t be fucked』: 過小評価されている技術的負債の原因
(jesseduffield.com)- 開発力は知識だけで決まるものではなく、やるべきことを分かっていても モチベーション不足 のせいでテスト・リファクタリング・再現ケースの作成を先延ばしにすると技術的負債が積み上がる
- 優れた開発者は flaky test を調査して修正し、見つけたバグをチケット化するか即座に直し、新機能が既存コードに合わないなら先に リファクタリング する
- "premature optimisation"、"duplication is better than the wrong abstraction"、"Keep It Simple, Stupid" のような格言は実際の制約を扱うときに有用だが、単に やりたくなさ を隠す言葉としても使われうる
- Lazygit では数か月かけて end-to-end テストシステムを作り、その効果を実感したが、Lazydocker には同じテストを追加せず、最小再現リポジトリの依頼や God Struct のリファクタリングも先送りになった
- 完璧なコードを書くエネルギーがないときでも、不十分な点を率直に示せば、保守の基準や次に何へ時間を使うべきかを判断しやすくなる
技術的負債を生むモチベーション不足
- "Can’t Be Fucked" は、何かをしたくない、あるいはそれをする エネルギーとモチベーション がない状態を指すオーストラリア英語の俗語
- 開発の知識をたくさん学べばより良いプログラマーになれると思っていたが、実際に尊敬するようになる開発者は、知識だけでなく 継続的な実直さ を備えた人たちだった
- 良い開発者は、問題が小さいうちにきちんと対処したほうが長期的には時間の節約になると理解し、実際に行動する
- flaky test があれば調査して直す
- 本番環境でバグを見つけたらチケットを作るか即座に修正する
- 新機能が既存コードに合わないなら、無理やり押し込むより先にリファクタリングする
- 必要であればスタックの下層まで降りて原因を突き止める
- こうした開発者たちも、"good enough" が正しい場合、スコープを縮小すべき場合、ドメインをもっと学んでからアーキテクチャを変えたほうがよい場合を見分けている
- 問題は、そのような判断とは別に、ある瞬間にはプロジェクトの外部制約よりも モチベーション欠如 のほうが強い制約になってしまうことだ
格言の陰に隠れず、正直になる
- Lazygit の end-to-end テストシステムは数か月にわたってパートタイムで作り、その後多くのリグレッションを防いだし、今になって追加しようとすればもっと難しかったはずだという確信がある
- それでも Lazydocker に end-to-end テストを追加しなかった理由は、単純に CBF だった
- 別のオープンソースリポジトリに issue を立てたあと、最小再現用の Git リポジトリを求められたが、まだ作っていない。また、1年以上前に始めた大規模なリファクタリングも終えられておらず、コードには今も God Struct が多く残っている
- それがバーンアウトなのか、成長マインドセットの不足なのか、性格の問題なのかは断定していない
- 技術的負債の長期的な痛みを知っていることは回避の動機になりうるが、知っていること と実際に正しく行動することは別物だ
- 「テストが多すぎると保守負担が生じる」「他の機能にどんな影響があるか見てからリファクタリングする」「premature optimisation」「cut scope aggressively」といった言葉は良い判断にも使えるが、言い訳にもなりうる
- コードや pull request の一部が不十分な理由が怠慢だと認めれば、レビュアーはその不十分さが基準を下回るか、それとも次の作業に時間を使ったほうがよいかを自分で判断できる
- CBF 状態になったときは落ち込むより正直であるべきであり、あまりに長く100%で走り続けてきたなら 休暇 が必要なのかもしれない
1件のコメント
Hacker News のコメント
CBF のかなりの部分は、報酬とインセンティブだけでも説明できる
今の会社に入ったときはエネルギーに満ちていて、壊れたビルドを直し、放置されたテストを通し、デプロイパイプラインをリファクタリングし、バグの根本原因を突き止めて修正していた
ところが時間がたつと、人々は私を見習うどころか「どうせあの人が直すだろう」となり、雑用をやるとさらに多くの雑用が回ってくるだけだと分かった
逆に、適当にハックするように作る人は、成果をうまく見せて先に昇進し、本番運用で問題が起きるころにはすでに別のプロジェクトへ移っている
私が毎週何時間も手助けしているジュニアは、2022年に急いで採用されたおかげで私より多く稼いでおり、私は2023年に「期待以上」の評価を受けたが、厳しい時期だからと昇給もなかった
結局、給料をもらって働く立場で、努力が報われないどころか罰になるなら、モチベーションがなくなるのは不思議ではない
そこを離れて、自分のいるべき場所と自分の仲間を見つけるべきだ
認められればモチベーションのコストは大きく下がるし、人は報酬を好む
人々がゲームを何千時間もプレイするのも、モチベーションのコストが非常に低いからだ
職場をゲーム化しようという意味ではないが、自分で自分を擁護するとみみっちく見えるので、同僚同士で互いを認め合う必要がある
技術的負債にもそれぞれ異なる利率があり、腕の見せどころは 0% の負債を放置して高利の負債から返すことにある
地下室のクローゼットの床を張っている途中で資材が足りなくなり、奥まで完全には張れなかったとする。見た目は少し不格好だが、いつも箱で隠れていて、何十年住んでも影響はない。これは 0% の技術的負債だ
一方、排水路が詰まると、時間がたつほど地下室の水漏れや排水路の脱落で費用が大きくなるので、利子が付く負債だ。玄関の階段が壊れていて何度もつまずくのも、早く直すべき高利の負債だ
エンジニアリングでは、すべての機能開発を遅らせるアーキテクチャ上の問題が高利の負債になり得るし、ほとんど触らないファイルの汚いコードや TODO は、実際には低利の負債かもしれない
エンジニアは一方では 0% の負債を直すことに時間を使ってもっと重要な仕事を逃し、他方では「プロダクトやリーダーシップが技術的負債の解消を支援してくれない」と言うが、実際のコストと利率をうまく説明できていないことが多い
上から下まで、新しくて輝いているものだけが注目され、既存のものを維持する仕事には関心がない
たとえ重要性を説得できたとしても、経営陣はその仕事が必要だと同意するだけで、人事評価には何のプラスの影響もない。失敗すれば叱責されるだけの仕事を私が背負うことになる
コードベースが汚く一貫性がないと、隠れたファイルであっても、開発者は新機能を一貫性と品質を保って実装しようという気持ちが薄れる
「どうせこのモジュール全体を書き直さなければならないのだから、とりあえずここに雑に付けておいて、後で整理しよう」となる
https://en.wikipedia.org/wiki/Broken_windows_theory
技術的負債という表現の自然な拡張で、要点を簡潔に伝えられるので、会社でも使いたい
だから「開発者が実際のコストを説明できなかった」と責めるのは、少し安易な言い訳だ
顧客に見える問題が起きれば解決される可能性はあるが、内部の問題にすぎないなら、その可能性ははるかに低くなる
「0% の技術的負債」のような表現を真面目に使うときは、もしかして概念の捉え方を間違えているのではないかと振り返るべきだ
負債は返済するか利子を払う必要があるものだが、そういうものがないなら負債ではない
次は、まだ実装していない機能も 0% の技術的負債と呼ぶつもりなのだろうか
Steve Jobs のファンではないが、職人気質と細部に気を配る姿勢についての彼の引用はいつも好きだった。
「美しいチェストを作る大工なら、壁に向いていて誰にも見えない裏側だからといって合板を使ったりはしないだろう。自分にはそこにあると分かっているから、裏側にも美しい木材を使うはずだ。夜に安心して眠るには、美意識と品質が最後まで貫かれていなければならない」
ソフトウェア全般は、「要件を技術的にかろうじて満たしたのだから自分の仕事は終わり」という態度に大きく苦しめられていると思う。
https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...
基準に満たないハードウェアやソフトウェアは出荷を拒み、正しい仕様で作れなかった人を解雇したという話も多い。
一方でほとんどの人は、「できるだけ早く終わらせてもっと売り、品質テストだけ無事に通るよう必要なところは適当に合わせろ」という、正反対のリーダーシップの下で働いている。
実際の大工は市場で競争するには実用的で費用対効果が高くなければならない。
誰も見ない場所に高価な木材を使ったり時間をかけたりすれば、スループットは落ち、顧客コストは不必要に上がる。
職人にとっても時間とお金は有限であり、見えない作業に費やした時間は、より目に見える作業に使えなかった時間だ。
同じ腕前の大工たちがより低コストでより多く生産する市場では、そういう大工は押し出されるだろう。
ソフトウェアの問題は、態度というよりインセンティブの問題に近いと思う。良い仕事をして良いソフトウェアを使うのは好きだが、1日の時間は限られているし、自分が利益を得ない事業上のメリットのために個人の時間を犠牲にするほどではない。
しかもリファクタリングを始めれば、ある日突然、今日中に終わらせなければならない必須機能が出てくるだろうと合理的に予想できる。
経営陣が技術的負債の解消に同意したとしても、結局は見積もりを膨らませ、割り当てられた仕事の代わりにリファクタリングしなければ解決しない。
ある本で、鍛冶屋の人物が馬車の部品を直しながら「いつでも自分にできる最善を尽くせ」と言う。
「それは下に入る部品だから誰にも見えないじゃないですか」と言われると、「だが私はそこにあると知っている。自分にできる限りうまくやらなければ、その馬車が通るたびに恥ずかしくなるだろう。そして私はその馬車を毎日見ることになる」と答える。
https://news.ycombinator.com/item?id=28086786
まともな単体/統合/E2E テストを書き、ひどいコードを見たらその上にさらに積むのではなくリファクタリングすると、チケットを次々に「解決」する同僚より、書類上の生産性は低くなる。
特にリファクタリングやコード品質の整理をまったく考慮しない「完全アジャイル」な組織では顕著だ。
Apple は少なくとも一時期は例外だった。製品価格が高く、顧客は品質を期待しており、会社にはそれを可能にする利益率があり、何より体験を見抜く目を持つ Steve Jobs がいた。
反対の極端な例としては、宇宙航空級のエンジニアリングでジュースパックを絞る機械を作った Juicero のような事例もある。
キャリアの大半では、言われなくても機会が見えれば技術的負債を片付けてきた。愛着とオーナーシップがあったからだ。
今は Jira ベースのマイクロマネジメントと自律性のない職場なので、必ずやらなければならないこと以外は何もしない。
以前は自発的な努力がキャリアの中核だったが、今ではどんな変更にも官僚的・社会的なプロジェクト管理コストが大きすぎて、わざわざやる価値がない。
製品が長期的にうまくいくか、会社が成功するかには関心がなく、次の仕事を見つけるまでチケットを処理するだけだ。
逆に「リファクタリングは許可を取らずにやれ」という感じで進めると、リポジトリの既存パターンに従っていない PR を作ったとして叱られる。
「良いとは思いますが、チーム全体と議論する必要があります」になる。
そうして技術的負債は増え続け、PR 1本をマージするのに何カ月もかかり、テストはあまりに不安定で、ビルドが通るまで再実行ボタンを押すカジノのスロットマシンのようになる。アジャイルは本当に素晴らしい。
反応的にしか動かない職場で先回りして行動することは、私の経験上、絶対に報われない。
問題を見つけた瞬間にそれは自分の問題になり、後でまた噴き出せば自分が壊したことになる。
PM や管理層はいつも否定的な前提で動くので、その価値はない。
特に、自分には良いコードへ至る悟りを開いた道があると思っている人もいるが、実際には既存コードを読んで理解するより楽な道を選んでいることが多い。
ここのコメントには少し誤解がある。
個々のプログラマーにとって、動機、努力、エネルギー、意志力――何と呼ぶにせよ――は有限のリソースであり、それはまったく普通のことだ。
組織の利点は個々のプログラマーより多くの仕事を成し遂げられることだが、複数の要素をつなぎ合わせる過程で隙間が生まれ、仕事がその間からこぼれ落ちる。
COO、HR、プロダクトマネージャーのように、技術業務ではなく組織運営で給料を得ている人たちは、その隙間に対処するプロセスを作らなければならない。
ところが、ますます多くの会社がこの仕事を個々のエンジニアやデザイナーに押しつけている。損益や OKR で測りにくいからだ。
会社は苦しみ、エンジニアは燃え尽きる。追加報酬なしに、隙間からこぼれた小さなチケットや業務を拾い続けるのには限界がある。
ここは否定的な空気がものすごいけれど、この記事が自分の日常的な感情を正確に説明してくれていてうれしかった
オープンソースプロジェクトのすばらしいテストカバレッジや原則に沿ったリファクタリングを見ると、自分もある日は「ちゃんとやろう」モードになって、よくできたものをたくさん作れる
そしてある日そのエネルギーが消えると、著者のように自分もCBFになる。テストを飛ばし、良くないと分かっている場所にコードを継ぎ足し、未来の自分がありがたがらない道を敷いている
それがリアルタイムで見えているのに、インスピレーションに満ちた「ちゃんとやろう」モードへ戻るエネルギーや動機がない
これは全部、自分で作って売っているソフトウェアでも起きている
著者がLazygitを作った人だと知って印象深かったし、lazygitは本当に好き。自分の中ではいつも、きちんとやり遂げるオープンソースメンテナーのカテゴリに入っている
私たちはどちらも、動機について似た経験をしているようですね
lazygitを気に入ってくれてうれしいですし、今後も良い評価を保てることを願っています
ほとんどの意思決定は実は無意識的なもの
「どうしてもやる気になれない」という状態は、脳のどこかの回路が、リファクタリングやテストのような作業にはやる価値がないと判断しているという意味
その回路が正しいこともある。客観的かつ全体的に見ると、努力に対する報酬が実際には十分でない場合が多いから
例えばエンドツーエンドテストを2か月かけて作り、その後6か月でデバッグなどの時間を3週間節約できたとしても、計算が合わない
よくある両極端がある。一方ではビジネス側が、本当に悪いトレードオフである技術的負債をエンジニアに強要し、もう一方ではエンジニアが、結局報われない理想的な構造化や巨大なテスト群に時間を使うこともある
その一部は、誰かがより良いコード構造や追加テストを見つけて自分を評価するのではないかと心配するからでもある
自分の基準に満たないものを出していると感じると、その基準が実際の必要より高かったとしても、士気とモチベーションが大きく損なわれる
技術的負債の最大の問題は、むしろ士気を壊すことにあると思う
Lazygitにはエンドツーエンドテストシステムを数か月かけて部分的に作ったし、そのシステムが防いだリグレッションや、今になって追加しようとしたらどれほど難しくなるかを毎日考えている
明らかに価値があったと分かっているのに、なぜLazydockerにはエンドツーエンドテストを追加しなかったのかというと、単にCBFだから
エンドツーエンドテストは、道具がきちんと揃っていないと地獄のように面倒で、とてつもない作業になる。簡単に組み込める基本フレームワークがもっと良くなる必要がある
運が良ければ、その人に統合テストまで見る時間が残る
この社会とこの世界で、人々を怠け者だと見る視点は、だいたい馬鹿げていると思う
何十年も週40時間働いて、生まれ変わってからようやく休めというようなものなのに、ここで怠惰を語るのかと思う
精神的エネルギーは他人の富を生み出すために吸い取られ、年を取りすぎて何もできなくなると捨てられる
毎週、昨日終わっているべきだった機能がまた出てくるのに、技術的負債をいつ直せというのか分からない。自由時間にやれというのか？ そもそもなぜ存在し続けなければならないのかも分からない
小さなチームの成熟したプロジェクトでは、残っているチケットが全部、誰もやりたがらない難しいバグだった
何日も費やしても、疑わしい箇所をいくつか消せた以外に見せられるものはなく、間違って消すと1週間後にまた戻ってくるようなバグ
毎日すべての精神的エネルギーをそういうチケットに注がなければならず、コーヒーや刺激剤に頼ってようやくバグを解決したら、コードを提出してチケットを閉じ、すぐ次のチケットへ行かなければならない
本当の休息はなく、次のチケットの序盤に誰も即座の結果を期待していないときだけ、少し頭を休められる
でも数日経つと、人々がこれまで何をしていたのか、詰まっているのかを尋ねてきて、実際にはほとんど始められてもいないのに、遅れている理由を小さな嘘で取り繕わなければならない
いちばん休む必要があるときには、すでにいちばん遅れていて周りに気づかれた後なので、休暇を取ることすら選択肢のように感じられない
今はエンジニアリング系の非営利で週20〜30時間、ときにはそれより少なく働いていて、お金は厳しいが、これ以上働くのはどうしても無理
サイドプロジェクトと自転車に乗る時間が少しあり、週末は絶対に働かない。火曜日も特別な場合でなければ働かない
今の職場は本当に大好きで夢の職場だけれど、自分を殺してまでやる価値はない。人生は一度きりで、ちゃんと愛しながら生きるつもり
今日、会社のデバイスファームウェアをほぼ全面的に書き直す1か月の作業を終えたが、最初は通信モジュールの一部の小さなバグを直す1週間の作業として見積もられていた
幸い、のんびりしたPMと同僚たちがいて、そのコードにある8年物のレガシーバグを実際に直せるようになった点を認めてくれた
まだエッジケースのテストと追加修正は残っているが、リモートコード更新が動くのでデバイスを出荷できる
ここでの「嘘」は行動の推奨に近い。もともとはコメントを「嘘をつけ」で始めたのだが、誤解があった
同僚たちに、仕事のより広い含意について考える時間を持つことが重要だと伝えるためにも存在すべき
こうしたコミュニティに自分の考えを加え、チョコレートを食べ、可能なら犬を散歩させ、YouTubeでAlan Wattsの講義を聞くためにも存在すべき
きちんとやろうと努力している人間として、技術的負債で重要なのは追跡だと思う
目に見える問題をタスクとして1つ登録するのに数分しかかからず、そのタスクが技術的負債になる
リーダーシップには技術的負債の優先順位を決め、一定量を継続的に減らしていく責任がある
ときには何かをやらないと決めることで技術的負債を減らすこともあり、それもまったく問題ない
記録し、確認し、処理する手順の目的は、「今ではない問題」をもう一度見直す機会を与えること
最初の直感が間違っていてXは不要だったのかもしれないし、逆に当時は思いつかなかった理由で正しかったのかもしれない
何より、「今はできない」ことの中には実際に重要なものがある。時間をかけて見てみなければ、そういうものは見つけられない