超高速な開発ができるわけ | Yakst

あるひとりの人がシステムを作ったが故にそのシステムに精通している場合に、最も生産的な開発が行われる。しかしこれは、ひとりの人がシステムの面倒を見ることを超えてシステムが成長する時には矛盾してしまう。 ある状況下において、特定の開発者たちが他の人の10倍生産性が高くなることがあるのはなぜかについて議論してみましょう。 ヒント : 開発者の話ではなく、状況が大きなカギ。 生産性が非常に高いことにウキウキした気分になるのはいつでしょうか。新しい機能が指先からあふれ出てくる時？それは、私たちが関わるツールのことを知り尽くしている時、あるいはもっと決定的に言うと、自分がシステムを変更しつつある時に起こるのです。自分のバックパック、それも自分で詰め込み、そしてひとつひとつの小袋の中まで何年にもわたる旅行を経て調整してきたバックパックの中身を知っているように、システムを知ることです。それぞれのモジュール

[cu39]

「複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単である」

[hyperpeppy]

これはその開発者本人だけでなく、その上のリーダー達にも知ってほしい。その開発者が出してきた見積もりそのままで機能改修を外部に発注するんだから…

[tbpg]

"「〜なだけ(just)」「簡単(easy)」「明白(obvious)」「単に(simple)」「分かりやすい(straightforward)」といった単語は辞書から消してしまいましょう。これらの単語には背景が必要で、その背景を理解している人などいないのです"

[hatest]

自分ではホワイトボックスでも、他の人はブラックボックスに見えるということを意識して仕事しろ

[sgo2]

受け売りだけど、コードを書くのは1回だけだが読むのは何度も繰り返す。また機械はどんなコードでも読み取ってくれるから、人間に読ませる事に注力した方がいい。

[ono_matope]

"Braitenbergはこれを、「下りの発明、登りの分析の法則(Law of Downhill Invention, Uphill Analysis)」と呼んでいます。複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単であると" だよね。

[turanukimaru]

思い通りにできるなら生産性は10倍にもなるが、思いなんてものは結局個人のものだから全体ではそんなにならない。テストを書くのはお勧め。テストコードはサンプルコードとしても機能するから。

[iTaro]

“10倍の生産性で開発するべき時と、チーム開発すべき時があるということです” 1度10倍の生産性で開発する快感を知ると、チーム開発が嫌になる罠。俺はもっとできるはずという充足感のない日々に惑わされた過去

[perl-o-pal]

知識のシェアって目的ならペアプロじゃなくてもコードレビューとかで良いような気がするが、まあペアプロの方がより良いのかな。

[otihateten3510]

こういう理想論で何か解決した気になってるエントリーが大っ嫌いだ。皆できないから困ってる。あと「超高速な開発ができるわけ」の解になってない。トレードオフの片方の重要性を主張してるだけ。

[stilo]

『まず、(今のやり方自体は)変えないことです。これはソフトウェアを最も高速に開発する方法です/テストを書いてください/ペアプログラミングしましょう！/ペアプログラミングしましょう』

[moccos_info]

“「下りの発明、登りの分析の法則(Law of Downhill Invention, Uphill Analysis)」と呼んでいます。複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単であるということを表しています”

[fuktommy]

こういうの見ると毎度思うけども、仕事でプログラミングしたくない。 超高速な開発ができるわけ | Yakst @yakstcomから

[oukayuka]

わかるわー。とりあえずタイムリミットまでに3を仕組み化したい。5も引き受けようかな。

[ohbarye]

“他の人の10倍の生産性で動ける開発者と状況の組み合わせが本当にあり得るということを知っておきましょう。そしてそういう状況はスケールしないということを知っておきましょう。”

[sagaraya]

“複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単である”

[t2wave]

“10倍の生産性で開発するべき時と、チーム開発すべき時があるということです。真剣に開発したい時には、10倍の生産性で開発する開発者は邪魔になります。そういった時には、この記事に書かれた提案のことを考えて”

[taky1973]

http://www.megamouth.info/entry/2017/08/01/083126 と併読することで生まれるモヤモヤ感

[lorenz_sys]

正に自分はこのような状況で開発しているがやっぱりそれは続けるべきじゃないと思っていた。この記事の落としどころが自分の考えとまぁ同じだったのでちょっと安心。ただしもうちょっとの間はこの生産性を維持する。

[daikiueda]

“「下りの発明、登りの分析の法則(Law of Downhill Invention, Uphill Analysis)」と呼んでいます。複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単である”

[lucifer_af]

「他の人の10倍の生産性で動ける開発者と状況の組み合わせが本当にあり得るということを知っておきましょう。そしてそういう状況はスケールしないということを知っておきましょう」

[zaki1010]

これは重要なのにあんまり意識してなかった…。

[rjge]

“多くの場合、既に誰かが書いたシステムを触る必要があります(「誰か」は「数ヶ月あるいは数年前の自分」の可能性もあります)” 数ヶ月前の自分なんて他人同然どころか他人以上に理解できん存在だからな…

[uskey]

技術力というハードルなのかプロダクトへの理解というハードルなのか 、現場でやっているとまともに判断出来なくなりがちなので心に留めたい

[lenore]

歳を取ると昔自分が作ったものも記憶が薄れてしまうから、そういう意味でもテスト作成＆解りやすいアウトプット必要

[adrlife2343]

生き字引みたいな人に出し惜しみされると本当辛い。自分が一番貢献しているって顔して、一番罪深いんだよなぁ。うまく賞賛して引き出してチームのものにするプロセス大事。

[gnt]

狭義に限らない話。あと「超高速な開発ができるわけ」は書いてある。「『10倍の生産性』は属人にしてコミュニケーションコストを払ってないことの引き換え(なので、ある場面では超高速な開発は避けるべき悪)」

[natu3kan]

いろんな人が長時間つづける必要のある仕事であっても、問題が発生しないかぎり属人化しがちなので、他の人が出来るように手間かけて共通化したりマニュアル化するのは大事（実際は時間とコストの都合で属人化する）

[hiroponz]

分かる

[tanority]

いい話

[heavenward]

わかりみとつらみが同時に襲ってくる良記事

[higed]

テストを書いてください。テストは、意図せず何かを壊してしまうことを恐れている人が、今からやろうとしていることを試す方法です。

[tinsep19]

いま成長して、問題となっているような場面になったので、自分が抜けたチームで作り直してもらいたい。そうすれば下りは発明を彼らに経験させられるだろうか？

[Eiichiro]

自戒しておこう。

[sds-page]

最新技術についてこれないおっちゃんにも優しくしよう

[atwata]

わかる。システムってのは超属人的なもの

[vndn]

『あなたがそのシステムに熱中しているその人なら、「〜なだけ(just)」「簡単(easy)」「明白(obvious)」「単に(simple)」「分かりやすい(straightforward)」といった単語は辞書から消してしまいましょう。』

[tksthdnr]

わかっちゃいるけど難しいやつ