なんのかんのと現実の世は9割以上はウォーターフォール（レビュー後の再実施無し版）。 ペーペーのころから感じていたしっくり来ない感ってか、無理だろ感はこの一言で氷解した。 こいつは将棋を指す時「詰み」まで読み切ってから始めるのか？ アジャイルと…

知らないと恥をかく プログラミングの常識 http://d.hatena.ne.jp/bleis-tift/20090301/1235850947 いろいろ突っ込みの量ってか分量書き上げたところに感服した( ´∀｀) 今日の笑いを提供していただいた気持ちになれたのでとっても感謝（−人−） より良いコー…

Agile失敗パターン三部作 http://d.hatena.ne.jp/masayang/20090227/1235782899 未知の技術を採用したり、未知の領域のアプリを開発したりするような場合には、プロジェクトはそれなりの(把握できない)リスクを抱える事になる。 だとしても、プロジェクト終…

絶望を表す言葉には多々あるが。 例えばこんなソースコードを見たときの気持ちを的確に表せる言葉をボクは知らない。

仕事の話の中では ・効率化の推進は計画的にやるのは当然 ・つじつまあわせ厳禁 ・間違えて禍根を残すようなら作り直し ってこと当たり前だとおもうやん。 実際自分じゃ思ってるやん。 唐突だが昨日、障子を張り替えた。 1枚失敗した。 ちょっと皺よったから…

目の前の不満は言っても言うだけじゃ解消しないもんだ。 やるだけやろうってコトに落ち着くな。 さー今日もがんばろ。

世の中の多くの人々が共有している知識がある。 世の中の多くの人々が共有している感覚がある。 それでもそれが実行できるかどうかはコトによる。 だってほれ。 30cm物差ししかない状況で2mの直線が引ける人間がどれほどいるというのだ？ 物差しがあれば直線…

ソフトウェア開発作業がなんで難しいんだろなんて思っているのだが、 ふと思いついたことがあった。 (1)人員の中で最高レベルが高いことが必須。 (2)方向付けする旗振り役が必要。 (3)最高レベルを理解せずとも真似できるだけの要員も必要。 (4)それ以外は(3…

プログラム作りを工程的に３割くらいしかないからそんなに重要でないとかいうアホは、 例えばフレームワークは誰が作るか考えてから出直してくるといい。 何が出来るか、どうやって出来るかを事前に考慮して計測して方向性決定しますってゆー ウォーターフォ…

masayangさんとこ経由。 従来のソフトウェア工学が決定的に間違っている点 http://d.hatena.ne.jp/kwatch/20090204/1233769288 問題を解決できない人間を100人集めても、問題は解決できない。問題を解決できるのは、問題を解決できる能力を持った人間だけ。 …

こちらの記事より。画面設計とか外部設計とか、もうやめようよ http://d.hatena.ne.jp/masayang/20090129/1233202874 ふっと思いだした昔の体験談。 http://d.hatena.ne.jp/tonotonotono/20070824 ゆめいっぱいの複雑怪奇な画面設計が行われ、 実装も細かい…

この本のレビューを見た。ワロタｗ http://www.amazon.co.jp/review/R3OWYB9YE1YFS4/ref=cm_cr_dp_cmt?%5Fencoding=UTF8&ASIN=477413628X&nodeID=465392#wasThisHelpful レビューの中で紹介されてた「ツールいらずの〜」ってページみた。ワロタｗ http://gih…

レシピ通りに作らないのがマズメシクオリティ。 ウマいメシとマズいメシの差は材料と手順もさることながら「人」が大きいな。 先日なにげにテレビ流していたらクッキングな番組やってた。 料理の先生が簡単なレシピでおいしいデザートを〜ってやつ。 手順は…

自分の守備範囲を頑なに固持するってのはよくないな。 機能毎のインタフェースがあっても、 機能間の連携箇所が無考慮なため、 なにか作れば何か出てくるってことが起きている。 っつかね。 ナンボ急ぐプロジェクトだからって言っても、 ＣＶＳだのＳＶＮだ…

怠惰で優雅な時間というのもいいもんだが、 通勤で読書な時間というのもいいもんだ。 っと思っていた時期がボクにもありましたよ。新・ソフトウェア開発の神話 成功するプロジェクトチームの科学と文化 (IT Architects’Archive ソフトウェア開発の課題 11)作…

あけてました。 今年もよろしくです。