アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山本大@クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基本的にニッポンの受託開発のプロジェクトの場合は、大きく2つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ
僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。 それには理由がある。 それは、プログラマの誇りを見せたいからだ。 この案件は、既存機能をコピーして似た機能を作るというものだ。 既存機能は、Webシステムなのに1アクションで 1分や2分以上のレスポンスタイムはザラで、 悪いときには数分後にタイムアウトして、 さらに悪いときには、アプリケーション全体をロックしてしまっていた。 顧客はそれでも我慢して使っていてくれたそうだ。 今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。 それにしても酷いアリサマだとコードを見てみると 酷い。 確かにパフォーマンスは出ないのも無理はない。 いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。 この機能はそこそこ難しく、業務的にも重要だ。 しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコ
「A Guide to Hiring Programmers: The High Cost of Low Quality」という記事と、その記事への捕捉として後ほど投稿された「A follow up to "A Guide for Hiring Programmers"」という記事がありました。 プログラマの雇い方というタイトルではありましたが、内容はもう少し広いです。 一部著者の熱すぎる想いが加熱しているように見える部分や、アメリカ的事情に見える部分もありましたが、全体的に興味深い内容でした。 以下、2つまとめた要約です。 3番までが一つ目の記事で、4番以降が二つ目の記事要約です。 誤訳等が含まれている可能性があるので、是非原文をご覧下さい。 概要 Perlのコミュニティでプログラマを雇う事(特にPerl開発者)を話し合っていて、以下の点で知人達と合意ができた。 どのようなプログラミング
はてな界隈では、Javaって、あんま人気無いみたいだけど、ちょっと書かせてよ。 SIerでお仕事してると、派遣とか常駐とか言う形で、色んな会社に行って、違う会社の人とお仕事するんだけど、「経験年数n年(n>3)です」っていう人達が、恐ろしく使えなくてびっくりすることがしばしば。 特に、Java 5以降の機能 拡張for構文Enum可変長引数辺りを全く知らなかったり。 って言うか、Javaの極々基本的な知識である equals/hashCodeの実装Serializableの実装Iteratorの実装が全く出来ないんだよね…。 そういうのを知らなくても(出来なくても)業務をこなせちゃう(?)のが、Javaの言語特性だとは思わないけど、こういう人達だらけなんだよね…。 PMが新しい人を採用しようとして、ここら辺の知識を割りと厳し目にテストしたら、候補が10人居たのに全滅で、プロジェクトのスター
朝,出勤中に車で橋を渡ります。早起きして車を降りて,この橋で日本海をボーっと眺めながらコーヒーを飲むのが私のリフレッシュ法。ありきたりですが,この業界にいるとこんな自然とのふれあいが力をくれるものです。こんな感じでSHIHOのヨガDVDも買って,すっかり浮世離れを気取っている私です。情けない。。。 題名に気をつけていただきたい。「Microsoftのバグとの戦い」ではない。「Microsoftのバグ」との戦いだ。つまり「これはMicrosoftのバグだ!」という言いがかりとの戦いである。こう聞くと,「あぁ,駄目エンジニアとの戦いか」と思うあなたは,きっと高スキルエンジニア。そういう人ばかりだと助かる…わけではない。なぜなら,「これ,Microsoftのせいでしょ」と言いがかりをつけるのは,現場ではそれなりに権威のあるエンジニアであることも多いからだ。 今回はこの辺のMicrosoftへの言
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く