ソフトウェアは人を狂わせる
Software Drives People Insane
ソフトウェア開発の現場では、速度・金・複雑さ・抽象化・自由が組み合わさり、普通の人がバランスを失う。物理的な制約がないため変更コストが見えず、「できそう」が「すべき」に変わり、終わりのない改善とピボットが常態化する。著者は、本当に必要なのは「比例感覚」であり、すでに機能しているものに手を加えない勇気だと説く。
ソフトウェアが危険なのは、実行可能な行動が存在することと、実際にそれを取る必要があることを混同しやすいからだ。
HNでの議論
176- bob1029
ソフトウェア開発が顧客やユーザーの実情から切り離されると、人はおかしくなる。
開発者が定期的に顧客とやり取りすることを求められれば、この記事で描かれているような自由奔放な影響は大幅に減衰する。
開発チームが独房のような場所に隔離され、クライアントとの唯一のやり取りが「プロジェクトマネージャー」という名の刑務官がドアの下からメモを滑り込ませる形でしか行われないなら、狂気に陥る可能性は天井知らずになる。
顧客と仕事をするのは時に最悪だ。運動や野菜を食べるのが時に最悪なのと同じように。それは現実に足をつけておくための一時的な不幸なのだ。
- hliyan
今日のHNフロントページにある最新の「我々は技術/アーキテクチャXからYへ移行する」という投稿にこの考えを書こうとしていたが、今はここにふさわしいと感じる。
最近友人と、かつてはどれほど少ない開発者でどれほど多くのことができたかについて話していた。20年前、我々はミッションクリティカルなリアルタイムソフトウェア（トレーディングシステム）をC++で、20数名の開発者チームで開発していた。コアトレーディングカーネルチームは4人だった。社内製の分散プロセスオーケストレーションツール（フロントエンドもバックエンドもC++で書かれていた）は2人で作った。私自身、先物契約のポストトレードリスク管理システム全体を、たった一人で数ヶ月で作り上げたことがある。今日では、60〜80人のチームが、操作の大部分がCRUDで、末端に多少のトランザクション/キューの複雑さがあるだけのWebやモバイルアプリケーションに取り組んでいるのを目にする。
違いは技術の入れ替わりの速さだと思う。当時、ランタイムライブラリであれ開発時ツールであれ、我々が持っていた少数の依存関係は安定していた。標準ライブラリ、コンパイラ、unixコマンドとbashスクリプト、そしていくつかの内部ライブラリだ。我々の時間と集中力の大半は、適切なアルゴリズムとデータ構造を解明することに費やされ、コーディングは二の次だった。技術スタックやツールの選択、設定、更新、再設計、交換に費やす時間はごくわずかだった。
- tcdent
投稿者はソフトウェアを通じてエゴの影響を実際に観察しているが、それを定量化する能力にはまだ到達していない。
読み返して、与えられたすべての例をそのレンズを通して適用してみよ。
我々は人間性のこの部分を過度に表現する業界にいるのかもしれないが、異なる逸話を通じてどこにでも現れると確信している。プロフェッショナルな創造性に還元主義的な禅仏教の視点を適用すれば、これらすべては消え去る。
ボブは自分がヒーローになれるからサブシステムをリファクタリングしたいと思い、それを経営陣に正しく売り込めば、技術的メリットや実際に達成された成功の度合いは無関係になる。アリスは明らかな懸念をいくつか表面化して、あとは座って成り行きを見守ることを選ぶ。ジェーンはスタンドアップで両手を上げて、空が落ちてくると皆を感情的に説得しようとする。アリスのようになれ、そうすれば正気を保てる。
- randusername
私の観察は単純に、技術リーダーたちが、ある領域の一面の抽象的な表現を征服することで市場から得られる報酬を、領域そのものを征服することと誤解するということだ。そして彼らは誇大妄想になる。
あなたは働き方と社会の未来を切り開く商業用不動産を征服したのか、それとも便利なスケジューリングアプリを作っただけなのか？
オンラインコミュニティのための素晴らしいアイデアがあったのか、それとも人間のつながりを革命的に変えたのか？
- Terr_
2014年の投稿「Programming Sucks」[0]を思い出す。常に「こうあるべき」と思われる微小世界の中で現実から切り離されるという、いくつか似た問題に触れている。
> すべてのプログラミングチームは狂った人々によって、狂った人々から構成されている [...]
> 脳への破壊的影響は、人々が書くプログラミング言語によって示されている。 [...]
> すべてのプログラマーは、脳が決してするはずのなかったことを、決して改善できない状況で、1日10〜15時間、週5〜7日、脳に強制しており、その一人ひとりが徐々に狂っていく。
- cestith
ソフトウェアがこの影響を及ぼしているのか、それともソフトウェア製品に対するマネジメントがそうなのか？学術的あるいは趣味のソフトウェアプロジェクトで、自分たちにとって重要なことが気まぐれに絶えず変わるのをあまり見かけない。しかしソフトウェア業界では常に見られる。
- anigbrowl
ソフトウェアではない。ほとんどのマネージャー/管理者がソフトウェア開発者ではない（ある程度のプログラミング能力はあるかもしれないが）という事実だ。だから彼らは開発チームに対して、物理的な製品の機能についてメーカーに苦情を言う顧客と同じ関係に立つ。そして「こうあるべき、あああるべき、簡単に変更できるはずだ」と言う（実装の退屈な部分を飛ばして想像すれば、持っているのは簡単だから）。
もちろん、要求が正当で、元の仕様の何らかの失敗——野心の欠如か、あるいは芝刈り機のエンジンに貨物コンテナを繋いだような過剰な野心——に対処していることもある。しかし記事が描く対立のほとんどは、変更の利益を想像することと、実装はボタンをいくつか押すだけの問題だという暗黙の前提の組み合わせから生じている。
- msteffen
この枠組みが大好きだ。なぜこれが真実なのかについて多くの考えがあるが、私が思いついた最良の（私見では）簡潔な説明はこうだ：
1. ソフトウェア構築の多くはある種の数学だ。数学では、Xが真である理由を述べる証明を書く。ソフトウェアでは、Xが真であることを保証するコードを書く（例：「バックエンドはユーザーIDが常に利用可能だと仮定していたが、今はサービスアカウントがあるので、妥当なビューが依然として返されるようにアクセス制御コードを変更する必要がある」）
2. 数学は難しく、作業のほとんどは目に見えない思考だ。数学者にリーマン予想がいつ証明されるかの見積もりを尋ねたら、笑われるだろう。我々の問題は一般的にはもっと簡単だが、それでも難しいことがある。そして数学と同様、時に予想よりもずっと難しい（例：フェルマーの最終定理。「なぜそんなに難しかったのか？フェルマーと話したのか？彼は去った？でも簡単だと言ったはずだ！」）