パスワードを忘れた? アカウント作成
2194 story

Redmondのバグ潰し月間 84

ストーリー by Oliver
旧知なIRCでBug-Squashing-Party 部門より

yourCat 曰く、 "本家より、Goverment Computer Newsの記事によれば、Microsoftは同社のTrustworthy Computing Initiative部門において、2月末まで一切の新しいコードを書かず古いコードのバグ潰しに専念すると発表した。
「過去のバグ潰し」の機会なぞ今までにいくらでもあったと思うが、やらないよりはずっといい。普段からバグ潰しをしているはずなのでプロパガンダにも見えてしまうが、それでもバグ潰しに真剣に取り組もうという姿勢は好ましい。セキュリティーに対する取り組みも併せて、Microsoftは変わろうとしている。"

結果が楽しみだ。これを機会に開発者がこぞって休暇を取ってなければいいのだが。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • Chinese New Year (スコア:2, おもしろおかしい)

    by espy (3615) on 2002年02月04日 7時24分 (#59658) ホームページ 日記
    たくさんいると思われる中国系の開発者が旧正月で休みをとるから
    そもそもこの期間に新しいコードは書けない。なので設定した。
    …というのは邪推しすぎか?
  • バグ潰し (スコア:2, 興味深い)

    by Anonymous Coward on 2002年02月04日 7時37分 (#59660)
    ・何故か新しい機能が増えている。
    ・1ステップ操作する度に確認ウインドウが開く
    ・毎度責任がない事を使えるメッセージがでる。
    この修正では?

    または
    ・バグを潰すのではなくライバルの製品がある事が原因と考えよからぬ事を真剣に考えている。
    ・バグは当たり前と思わせれば修正できなかったとしても文句はないと思っている。
    ・実はマイクロソフトを止めたい
    ・パソコン画面に向かってバグを見ているだけで修正しない<新しいコード書かない為
     当然サイトの更新も止まる。↑3月から修正が始まり、4月に別製品として発売される。(笑)
    • by 11c (6985) on 2002年02月04日 22時09分 (#59843)
      ↑3月から修正が始まり、4月に別製品として発売される。(笑)

      で、XPSEプリインストールマシンが店頭に並ぶと同時に98SE以前のFIX提供が繰り上げ停止。

      # こいつは売れるでしょうね。

      親コメント
  • Microsoftの場合は「ニュース」になってしまうのですか...うらやましい

    というか、しらずしらずのウチに/.でMicrosoftを宣伝していることに気付いてくれと言いたい。
    • そうですね。ここもMSネタがなくなると、寂しいサイトになるでしょうねぇ・・・
      親コメント
    • ふと思ったんですけど、もしかしてコレって、暗に「Open Sourceの連中は
      ダラダラしてて、普段まともにコードなんて書いてないんですよ」ということを
      印象づけるための戦略かも知れませんね。

      「コード書きません!」って訴えるということは「それ以外の期間はマジメにやってます!」
      っていうことになるじゃないですか!

      信者のヒトはなおさら感心するでしょうよ、ったくもー。
      親コメント
      • 自分の場合ですが、コードを書くのは1晩でできます。問題は、それをやることが正しいのかを確かめることです。この作業は例えば1週間、あるいは1カ月という単位でかかります。私が最近やった、pgrpおよびsessionの細粒度lockでは、同時に取りに行くlockの数を少しでも減らすため、lockの順序を3回変更しました。これで値を変更しない場合はlockが1つだけで済んでいます。

        元記事も読んでみましたが、あくまでコードをさらうといっているだけで、その背後にある仕様やロジックに踏み込むとはいっていませんね。仕様書が与えられるだけの末端のプログラマに「仕様書を頭から信じて書け」というだけで1カ月終わる可能性もあります。

        親コメント
  • デバッグと言う名の… (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2002年02月04日 14時34分 (#59734)
    みんな、勘違いしてるね。
    これはバグを取るための期間じゃなくて、
    バグを見付けては仕様に加えていくための期間なんだ!
  • by Net2000 (6704) on 2002年02月04日 16時56分 (#59764)
    Bugレポートが、たまりすぎて処理量を超えたのでまとめて
    セキュリティ問題と合わせてまとめて処理したいということじゃ
    ないかな
  • この発表によって (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2002年02月04日 7時10分 (#59652)
    1.この発表によって、M$の株価が下がる。
    2.仕方なく方針を急遽変更して、またもとの体制に戻る。
    3.中途半端で終わったため、またバグが増える。
    4.使用者の怒りを買う。
    5.また会社の信頼が下がり、株価が下がる。
    6.仕方はく、「バグつぶし月間」を復活する。
    7.「1.」に戻る。

    世にも恐ろしい「株価下落スパイラル(ただし1社のみ)」の始まり、始まりぃー!。
    • Code Completeとか、Writing Solid Codeとか、Debugging the Development Process とか、
      そういう自社スタッフが書いた本を読み直す月間かもしれませんよ。

      McConnellの書いた本を時代順に並べてみると
      1994 Code Complete : A Practical Handbook of Software Construction
      1996 Rapid Development : Taming Wild Software Schedules
      1997 Software Project Survival Guide
      1999 After the Gold Rush : Creating a True Profession of Software Engineering

      他のマイクロソフトのコーディング本の著者たちもだんだん、
      プロジェクトマネジメントに移行したようですね。
      昇進して仕事が変わったのかもしれませんけど、みんなで
      バグを出さないコードの書き方も忘れていったのかしら。。。。
      親コメント
      •  Writing Solid Code や Code Complete は読みました。
         至極真っ当なことが書かれていて、駆け出しCプログラマだった当時の私にはなかなか参考になった記憶があります。
         Windows版 Excel を Mac に移植しようとした時の苦労話が印象的。

         個人的には、この三冊が発売された1994年~95年頃の Microsoft が、私の中での黄金期でしたね……
         ダイエットの本を書いている人が必ずしもダイエットに成功している訳ではない、ということですか?

        親コメント
    • by take0m (4948) on 2002年02月04日 12時16分 (#59703) 日記
      他(Linux関連も)は十分に下がっているので、ちょうどよいかもね。
      親コメント
  • by Anonymous Coward on 2002年02月04日 7時19分 (#59654)
    変わろうとしています、こんなにやっています、という「ポーズ」でもとっておかないと、そろそろ尻に火がついてきた、ということでしょうね。

    会社という集団ですから、実際の実務は一人一人は独立した人間のすること。

    そんなことやってられるか?と現場が思うほど士気が下がっていたり、トップにカリスマや信頼がなかったり、もう会社やめちゃおーかなー、なんて思ったりしている人がたくさんたくさんいる場合は、そうコトは簡単には運ばないはず。

    経営者の考えていることが、そのまま部下に伝わる、なんてことはそもそもありえないしね。

    指揮官の掛け声の後に、指揮官が後ろ(見方)から撃たれる、なんてのは、本当によくあるハナシだからね。

    このトップの発表を聞いて、現場では「もう、会社やめたほうが身のためだね」と思った、というか、その意志を固めた人がとても多そうですね。

    別の筋からの情報によれば、同社がどうなかった後、エンロンのような問題が出てこなければいいですけどね。心配だなぁ(楽しみだなぁ)。
  • by naka64 (4590) on 2002年02月04日 8時07分 (#59663) 日記
    「嘘だろ」「できるか」という [slashdot.org]が多いですね…
  • by Anonymous Coward on 2002年02月04日 9時17分 (#59672)
    (否定的なコメント多いですけど)
    あくどいことしてでも、
    方針転換してきたのがM$
    なんじゃないでしょうか?
    それで、2,3度失敗しながらも
    最後には自分のものにしてこれたのが
    経営としてすごい。

    と私は思います。
    • 2~3度、失敗しても、それに耐えられるだけの経済力がある。ってのが、一番凄いことだと思ってたりする。

      生き残れれば、勝ちなのだな。
      親コメント
  • 仕様の見直しも含めて、2~3年はかけないと・・・・・。
  • by kagechan (7132) on 2002年02月04日 14時16分 (#59733)
    私が経験してきたことからの想像なんですが、
    1.おい、市場から「貴社の製品はバグが多くって困るよ」という苦情が多くなってきててやばいよ
    2.じゃあ、バグ潰しのために人を割り当てないとなりませんね
    3.今出ているバグリストはこれだから、大体近い分野のことをやっている開発者に割り当ててしまおう
    4. 割り当てられたほうは、こんな部分のことなんて知らない!と思って慌てる
    5. その部分の挙動を理解するのに1ヵ月くらいかかる
    6. はい、タイムアップ!
    ということになっちゃうんじゃないかなと…。人月でしかものごとを見ることができないとこういうことは平気で起こりますよ。私の今の職場も似たようなものですしね。その問題のfix担当者に割り当てられてから1年くらいかけてようやくバグが分かって直したというのに、お客さんのほうのビジネスの状況が変わっていてもうそのfix はいらない、なんて言われることもしばしばです。
  • by nyaonyao (7735) on 2002年02月04日 17時22分 (#59768)
    現在、この会社が抱えているソースコードの量って、一ヶ月でチェックできる程度なんですか?
    一日に一人何行の割り当てで、何人が作業しているんでしょうか?
    今までのバグ報告の整理だって、一ヶ月じゃ無理だと思ってしまうんですが、どなたか納得できる情報を教えてください。
    • インドにだすもん。
      親コメント
  • ある程度きちんと直して、Windows XP SP1 は 775MB です、とか言われるのもまた困るんですけど。
  • わざわざ言う辺り、MSには「コードフィックス」と言う概念がないんでしょうね。
    確かにVSS使ってますが、いつまでたっても機能追加できてしまうエンドレス管理システムだったりする。

    結局、MSの製品のバージョンって「見栄えの違い」以外認識できない気がする今日この頃です。

    Windowsだって、結局いろんな機能拡張が出てきてWindows95でも、
    WindowsXPでも似たような事ができてしまって何が違うのかよく分らない。IEもバージョン変わってこんなに違うって余り思えない・・

    #まぁ、WindowsもIEもヘビーユーザじゃないからかもしれませんけど。

    「WindowsXPの仕様はこうだ!」って決まっていてそれを守りつつ、セキュリティパッチを出すと言うことはもうないんだろうか?
    --
    職業としてのプログラマ
    • by brake-handle (5065) on 2002年02月04日 20時09分 (#59811)

      Visual SourceSafeの機能 [microsoft.com]を簡単に調べてみましたが...

      • fileをcheckoutしたらcheckinまで他の人は一切いじれない(設定変更が必要)
      • 1つのprojectがsplitすることを考慮していない(branchが切れない、mergeができない)

      ...これじゃ、rcsよりひどくないですか? (rcsにもbranchはある) 並行開発が全く不可能です。どちらかというとdaily buildを重視した作りになっているようですが、そんなのは後付けでどうにでもなる(人になり代わって機械がcheckoutすれば十分)のに。 (こういう作りでいざと言う時に全く役立たずだったシステムを私は聞いたことがある)

      親コメント
      • > * 1つのprojectがsplitすることを考慮していない(branchが切れない、mergeができない)

        これは嘘でしょう.(ココ [microsoft.com])

        実際,会社で使っていますが,分岐はできます.
        ただ,その機能を使ったことはありません.
        # 他のプロジェクトでは,分岐を使用しています.

        そもそも,VSSは非常に使いにくいので,使い続けたくはありません.
        ファイルが消えたりとか,バックアップするには,どのファイルを取っておけば良いのか(レジストリも必要なのか?)とか,不安な要素も他にあります.

        VSSを使えば使うほど,MS社以外の生産性を落とさせるための陰謀じゃないかと,疑いたくなります.
        親コメント
        • >そもそも,VSSは非常に使いにくいので,使い続けたくはありません.
          >ファイルが消えたりとか,バックアップするには,どのファイルを取っておけば良いのか(レジストリも必要なのか?)とか,不安な要素も他にあります.

          わしも会社で試したことがあり、ファイルが消えたり
          はしませんでしたが、何故か更新したはずのファイルが
          古い状態になったことがありました。それ以来恐ろしくて
          もう使えません。

          #NT用のVCを手に入れるには、何故かIntel用
          #エンタープライズ版が必要なのが縁でVSSが手元にあるっす。

          --
          BURRN!
          親コメント
        • by SteppingWind (2654) on 2002年02月05日 11時44分 (#59987)

          >実際,会社で使っていますが,分岐はできます.

          今仕事で使っていて, 分岐が使えるなら使いたいのですが, VSSで言うところの分岐は実際の作業では全く役に立たないことが分かりました. 最も大きな違いは, CVS等では分岐後にも幹と枝の間に関連性が維持されますが, VSSでは分岐によって完全に独立したプロジェクトとなってしまうことです.

          これは次のようなシチュエーションを考えてみれば致命的に近い欠点であることが分かります

          • ユーザに製品をリリースしているが, このユーザ向けのカスタマイズが含まれているため分岐して管理している.
          • バグが見つかったので修正しなければならないが, これは共通部分だったので全てのbranchに適応しなければならない

          この時, VSSでは全てのbranchが独立したプロジェクトであるため個別に修正したソースの登録を人手でしなければならず, 作業ミスによるバージョン不一致が生じる可能性が高いです. さらに変更部分のマージチェックも有りませんので, branch独自の修正部分を重ね書きで潰してしまい, degradeを起こすという可能性も高くなります.

          以上の欠点から, VSSを

          • 本番系保守と開発が平行して進むような長期・大規模プロジェクト
          • 複数のリリースバージョンを平行して保守するようなプロダクトカスタマイズシステム開発

          の様な用途で使用するのは不適切であると結論付けられます

          親コメント
      • >他の人は一切いじれない(設定変更が必要)

        というか、たしか、デフォ設定がロック型管理になっているというだけだったような記憶が。

        ただ、共同所有について開眼(笑)していない人、つまり
        そのメリットを知らず、デメリット(というか憶測にもとづく恐怖?)ばかりを信じて
        いる人々にとっては、ロックがかからない管理方法ってのは
        本能的(笑)に怖くなるようですね。

        コードを書いたひとが後々のデバッグのセキニン(笑)まで負う、
        などという呑気なモデルを未だに採用してるトコロには、
        VSSは似合いのツールなんじゃないかな :-P

        ていうか、良い説得台詞を教えてください(T_T)
        実際にはファイルをロックしても「他のファイルとの関連」をロックできるわけじゃないんで
        ロックなんて徒労なんだけども、それを理解してもらうのは至難ですぅ…

        でもまあ、大人数(大企業にせよオープンソースにせよ)でナイ場合には、
        大勢のひとが同時にチェックアウトできないことのデメリットは
        あまり際立たないですけどね。隣人に一声かけるほうが早い(^^;

        ところでVSSは、MSのソフトとは思えないほど(笑)比較的使いごこちは良いと思います。
        あくまで比較的です。wordやexcelのような、何年たっても慣れられない
        変な操作性は、あんまり無いです。
        親コメント
        • checkoutされたfileをlockすることのデメリットとしては、CVS tutorial [sra.co.jp]のOHP [sra.co.jp]「衝突回避の一つのアイデア [sra.co.jp]」に挙がっています。一番つらいのは、fileを見るだけでもcheckoutするはめになること。見るだけならup-to-dateなものが必要とは限らないため、lockはするだけ無駄(どうせ変更は加えられない)です。

          複数fileのlock(CVSの場合commitの禁止)はCVSROOT/availでしょうね。最も、きちんとmoduleを管理していないと使いものになりませんが、これは何を使っても同じか...

          親コメント
        • でもまあ、大人数(大企業にせよオープンソースにせよ)でナイ場合には、大勢のひとが同時にチェックアウトできないことのデメリットはあまり際立たないですけどね。隣人に一声かけるほうが早い(^^;

          これと、remote accessができないということを考えると、開発者を全員1つの部屋に閉じ込められるならSourceSafeでも何とか使えるんでしょうかね。商用のツールでもperforce [perforce.com]のようにremote accessができるものがある(bkもそうらしい)ので、使い方に気が付いていないだけの問題でしょう。

          人数はあまり関係ないのでは? 私が関わってることなんか、USに数名、ヨーロッパに数名、日本に1名(あっし)って状態ですから。

          親コメント
  • by youphen (993) <youphenNO@SPAMgmail.com> on 2002年02月04日 21時49分 (#59841) 日記
    エイプリル・フールにはまだ2か月も早いですよ?
    --
    ゆーへん
typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...