ソフトウェア開発に「ちょっと変えるだけ」などない

「SMSを使う場面があるからレビューの長さを140文字以内に制限したいんだ。ちょっと変えるだけだよね？」，ソフトウェア開発の
現場でこんな要望を受けることはよくあります。

カスタマーサポート向けのSaaS（Software as a Service）を提供するIntercomのブログにて，「高品質のソフトウェアを提供しよう
思うのなら，ちょっと変えるだけなんてことはありえない」という主張とともに機能の全体像をしっかり検討し，その価値と見積りの
バランスを熟考することの重要性が説かれていました。

冒頭のような場合，経験の浅いプログラマは熟慮することなくif文を追加して数分で対応してしまうかもしれませんが，ソフトウェアや
サービスの質を高めることを目指すのであれば，考えることは山ほどあります。
・レビューが140文字を超えたらどうなる？
・エラーはどこにどんな文言で表示する？
・文字数制限の理由をユーザにどう説明する？
・エラーの見た目は誰がどのようにデザインする？
・クライアントサイドでもエラーチェックをするべきでは？
・JavaScriptが使えない場合はどんな動作になる？
・ユーザ視点だと，現在の文字数が確認できるカウンタがあったほうがよいのでは？
・実装後にはテストをしなくては
・最後はデプロイもしなくては

こういった判断は，経験豊富なプログラマであればその場で行えるものがほとんどですが，すべてのプログラマがそうとは限りません。
機能の全体像がよく検討されていない場合，2分で終わりそうに思える作業が2時間の作業になってしまうことはよくあります。
そして，2分の見積りであれば「良い価値」があると思えた機能も，2時間の見積りになるのであればスコープから外すことが
妥当なこともよくあります。

新しい機能に賛成するのは簡単です。コーディングはたいてい簡単にはいきません。そして，メンテナンスは悪夢になります。
高い品質のために努力しようとするのなら，「ちょっと変えるだけ」などあり得ないのです。
http://gihyo.jp/dev/clip/01/tech_information/vol76/0003