オフショア開発の問題点、意外と高いコストと開発チーム管理--米調査

http://japan.cnet.com/news/biz/story/0,2000050156,20096422,00.htm
メモ

オフショアの開発者を雇用することに期待する点として、コストの大幅な削減を挙げるという。しかし、すべての要素を合わせると、コスト削減は40％ほどしか達成できていないことが分かった。
「ほとんどの場合で満足は得られたようだが、もっと良い結果を期待していたことも事実だ」とRangaswamiは述べる。

「現地生産」の場合は為替変動のようなリスクに強いというメリットがあるそうな．ソフトウエアではこれはあまり意味がない．

インドには英語を話す人口が中国などの他のオフショア開発地域よりも多いために強みがあるとも述べる。

これについては日本だと全然強みにならないか．どうせほとんどの日本人は英語が話せないから．．．

らに、ソフトウェア企業は全体的に、オフショアリング化により、分散されたチームを管理できるようにプロセスの改善を迫られている

これは日本企業の大の苦手部分だね．できるのは「丸投げ」であって，マネジメントじゃない．従来のような「良きに計らえ」では何もやってくれなくても文句は言えない．

従うべきでないプログラミングのアドバイス10カ条

http://labs.cybozu.co.jp/blog/akky/archives/2006/02/10.html

8) 実世界に対応したクラスを設計せよ

これを勧めるOO入門書が後を絶たない．困ったもんである．

7) チームでコード記法を統一せよ

レベルによるな．例えば

C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス (C++ in‐depth series)

コレくらいなら許すが，改行位置だのセミコロンとの間の空白を入れるか入れないかだのを，厳しく取り締まるのは時間のムダ．最後は単なる宗教論争に発展する．

6) コメントをたくさん書け

これも微妙だ．
コメントが全くないコードというのは，大抵はド素人が書くもので論外だ．それじゃあコメントが沢山あればそれは良いコードかというとそうでもない．適切なコードが適量あるのなら良いが，冗長で「コードを見れば分かる」ようなことを繰り返し書いているようなものは鬱陶しいだけ．
通常は良いコメントは，綺麗なコードに適切なコメントが少量あるものだろう．ただしAPIのコメントは例外．これはインターフェースの外部に対する契約を表明するもので，一般的なコメントとは少し毛色が異なる．

1) コードを書く前に設計せよ

たしかに，これは最悪だね．でもコーディングができない人ほどこれを主張する．