バグを作ってしまったら？

先生！一度直すと次から次へと直す仕事が降ってきます！

もう〇〇が書いたコードを読むのには飽きました

# でも人間として可能な限りは直したい

アッーーーー!!乙。
なにその責任のとらせられ方こわい。

ぶっちゃけ、前ネタにしてから相当たつのにいまだにバグにバグをつんでくれてて納品できてないような素敵業者さんも、もし担当者が妙齢どストライクの女性で彼女になってくれるなら(略)
＃ということは、ありません。本当ですよ?
＃＃「お前は、本当にプログラムのセンスがないな。もう職業プログラマから足を洗ったほうがいい。」
＃＃「これからは、俺とお前の人生のプログラムを組んでくれ。」とかいう気はないですからね?
＃＃＃そして、影でデバッグしまくるというオチ
＃＃＃シラフジャナイノデ(略)

え? 男? ああ、「どじっこの男はもう全然だめだだめだ」とらき☆すたの中の人もいってたからだめです。
＃その判断基準もどうかと

バグ仕様書と、制限仕様書を急いで書いて送った記憶が遠い昔に。
今回搬入したものには、このようなバグがあり、この範囲内で取り扱ってください。
改善予定はいついつです。
…と時間稼ぎして(笑)ある意味デスマ的に一生懸命直す。
直しつつ、次の段階のリリースもしなくちゃいけませんけどね。

運用でなんとか回避できる範囲ならいいけど。
(えてして追加した新機能とか、それがらみでのデグレだから、ほんとごめんなさい。)

仕様書通りに作ったらバグレポート挙げられたでござる。

#まあ、誰もが通る道か

特に、担当者によって作業手順や解釈、定義が異なるのは勘弁して欲しい……
（ログインユーザ毎に処理ロジックが異なるシステムを作れと言うのか？）

そんなのは、その違うことを言う人双方宛にメールなり双方参加の打ち合わせで合意を取ってもらって返答もらうなり、文書に残る形で問い合わせて合意を取ってから実装すべきでは?
合意とらない実装してぐだぐだになるよりそういう習慣を作ったほうが双方にとっていいと思いますよ?

「ハードウエア『製造』の品質 ≒ 精度」に対し、
ソフトウエア『開発』 はハードウエアの『設計』に相当し、
「設計品質 ≠ 精度」なので、

「精度を測る部門」としての「品質保証部門」は無意味です。
設計の品質は、計測機器により測ることは不可能です。

ソフトウエア開発を知らない人が、ハードウエアの品質管理手法を
ソフトウエアに適用しようとして失敗する最大の理由がコレです。

個人的には完璧目指したいですが、やっぱり作る事もあります。

結局、バグの深刻度次第と金の天秤ですよね。
今は有効になってない機能とか、金払ってまで出来るかっとかありますし。
改修した奴を動くようにするためにお客さんが業務を止めないといけないとかになったら、
客が「じゃ、今回はスルーで、次の更新時に纏めて入れて」とかいうケースも有りうるでしょう。
「じゃ、業務停止に対する賠償ＸＸＸね、出来次第直ぐ入れて。」とかなるかもしれませんが。
結局客と相談が第一手だよね。
後は客がどう判断するか。

自分がするのは、もう諦観と次に作らないようにしないとって思うしかないでしょう。
新聞沙汰になってたらもう、自分一人でなんとかなるレベルじゃないだろうし。
後は再発防止を考える位ですかねー

# 正常系しか考えてなさそうなコード・仕様書を見ると無性にツッコミしたくなる難儀な子です。
# 日曜プログラミング時のコードはお仕事コードの5%でも異常系を考慮してる？的な出来ですけど。

バグだと思ってプログラムを止めようとするとPCが爆発、
そこで止めずにOCするとPCがエメラルド色に輝きだすんですね。