システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers
Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか
シンプルさが勝つ。人間はシンプルではない。 - mizchi's blog
迷ったらシンプルな方— 片手間以上 (@mizchi) 2014, 7月 19 僕は主にUIを作るエンジニアなのだけど、以下の話題について。 時間をかけて、つまらないものを作りたいか？ - futoase.hatenablog.com ニコニコ動画はSynvieプロジェクトが原型 - はてな村定点観測所 UIの有効性を証明する仮説とその検証において、ほとんどの場合において次の二つが根源的な問題となる。 だいたいのものはシンプルな方が勝つ 人間はシンプルではない 二点間の距離を求める三平方の定理は、(ディスプレイが歪んでいない限り)簡潔でシンプルだが、二点のボタンを順番に押すときのマウスの軌道、そのあいだのユーザーのメンタルモデルの変化は、まったくもってシンプルではない。 人間はシンプルなものの価値を認めたがらない、というバイアスがある。金を産まないといけないソフトウェア開発の現場は、コアフ
ssig33.com - DHH についての見解
DHH の主張って TDD は糞だ TDD によって「テストのしやすさ」が主眼となるため設計がむしろ歪む DCI は糞だ、 Concerns でいいだろ Concerns の結果として超絶巨大なドメインモデルが実行時に作られたところで知ったことではない とかそんな感じで、ある種の複雑さを許容しよう。結果として最適な設計を得られる。というような感じのことが多いと思ってます。 ソフトウェアというのは元来複雑なものです。結局のところ、その複雑さをどのレイヤーで受け入れるかというのが、ソフトウェア開発の本質の一つではないかと思います。 DHH の主張というのは、それを薄く広く受け入れろというようになっている。 一方で TDD や DCI の仕組みって人に何かをアサインする人が全体的な整合性を整えて、あとの人は目の前の問題解決に注力するみたいな形になりがちで、中央集権的と言えると思う。 つまらない話
スタートアップにおけるソフトウェア開発の無駄をなくす大事な３つの考えかた | Social Change!
資金も人も少ないスタートアップが大手企業に勝つためには、大手と同じことをしていては勝つことができません。大手にできないことをしてこそスタートアップは生き残ることが出来るはずです。もし仮に投資を受けて大手のような振る舞いをしたところで、そもそも基礎的な体力は違う訳で息切れしてしまうことは目に見えています。 大手企業とスタートアップの大きな違いは、大手企業は資金や人を沢山もちすぎているということです。それは正面から戦ったら強みになるでしょうが、新規事業においては弱点にもなりえるのです。 沢山の人や資金を動かすとしたら、必ず無駄が産まれます。長過ぎる会議や総花的な意見まとめなど大企業のオペレーションには多くの無駄があります。小さくて小回りの利くスタートアップが同じように振る舞う必要はありません。 ITを活用するスタートアップにおいて、ソフトウェアを作るという文脈の中でも、大手企業とは違う戦略を採
既存システムを分析するコツは「システムの地図」を作ること
ビジネス系のシステム開発では、まったくの新規システム開発は少なく、すでにあるシステムの再構築プロジェクトがほとんどです。このようなプロジェクトでは既存システムを調べる作業が必ず発生します。その割には公開された情報として、既存システムを分析する方法を説明したものを見かけません。多くは開発者がその場その場で臨機応変に対応しています。 実際のプロジェクトでは開始早々この既存システムの分析で手間取り、時間を大きくロスするケースが見られます。この連載ではコストをかけずに分析するモデルベースの方法を5回に分けて紹介します。第1回目となる今回は、詳細に踏み込まずにトップダウンでモデル化していくための考え方を示します。 プロジェクトが置かれた状況 既存システムは土台にできるか 既存システムの調査分析は時間ばかりかかり、なかなか成果が現れません。そんなプロジェクトでは以下のような会話が飛び交います。 佐藤さ
「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催
統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」（Empirical Software Engineering、実証的ソフトウェア工学）です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。 基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。 開発組織の構造がソフトウェア品質に及ぼす影響は？ マイクロソフトリサーチのDr. Thomas Zimmermann氏。 今日はいくつかのテーマについて紹介した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
