アカウント名:
パスワード:
そもそも「バグの数＝ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。なぜなら「バグがなければ本当に顧客が使いたい完璧なソフトウェアなのか？」は大抵の場合、ＮＯですから。
上流工程の段階から仕様をきちんと煮詰められる（プログラムで処理できるか、実装にどれくらいコストがかかるか、代替案があるか、を判断できる）人間が携わっていれば、そんなにひどいモノはできない気がするんですけどね。
＃でもスーツ着て客の前に出るのが面倒だから引きこもり気味の巫女なのでＡＣ＃ＡＣの意味がないのは芸風です（言い切った）
上流工程の段階から仕様をきちんと煮詰められる（プログラムで処理できるか、実装にどれくらいコストがかかるか、代替案があるか、を判断できる）人間が携わっていれば、そんなにひどいモノはできない
それができればこんなストーリーは立たない罠。
実際には、そういうことができる人から先に外されるのが常ですね。技術的な落とし穴を指摘すると、「後ろ向きな発言をするな」と言われたりとか、ありがちです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
そもそも (スコア:3, 興味深い)
そもそも「バグの数＝ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。なぜなら「バグがなければ本当に顧客が使いたい完璧なソフトウェアなのか？」は大抵の場合、ＮＯですから。
上流工程の段階から仕様をきちんと煮詰められる（プログラムで処理できるか、実装にどれくらいコストがかかるか、代替案があるか、を判断できる）人間が携わっていれば、そんなにひどいモノはできない気がするんですけどね。
＃でもスーツ着て客の前に出るのが面倒だから引きこもり気味の巫女なのでＡＣ
＃ＡＣの意味がないのは芸風です（言い切った）
Re: (スコア:0)
それができればこんなストーリーは立たない罠。
Re:そもそも (スコア:3, 参考になる)
実際には、そういうことができる人から先に外されるのが常ですね。
技術的な落とし穴を指摘すると、「後ろ向きな発言をするな」と言われたりとか、ありがちです。