ソフトウェア開発は、プロジェクトが行うこととプロジェクトを完了させることの間で常に妥協です。しかし、エンジニアリングやビジネスの感性を傷つけるような方法でプロジェクトの展開をスピードアップするために、品質をトレードオフするように求められることがあります。たとえば、ソフトウェアエンジニアリングの慣行が貧弱で、メンテナンスの問題が多く発生するような作業をするように求められる場合があります。
これが起きた場合は、まずチームに知らせ、品質低下のコストを明確に説明することです。結局のところ、あなたの理解はあなたの上司の理解よりはるかに良いはずです。何が失われているのか、何が得られているのかを明確にし、次のサイクルで失われた地面をどのようなコストで取り戻すのでしょうか。この中で、良いプロジェクト計画が提供する可視性が役立つはずです。品質のトレードオフが品質保証の努力に影響を及ぼす場合は、それを指摘してください（上司と品質保証担当者の両方に）。品質のトレードオフが品質保証期間後に報告されるバグを増やす場合は、それを指摘してください。
彼女がまだ主張しているなら、次のサイクルで書き直しや改善を計画することができる特定のコンポーネントに不自由さを分離しようとするべきです。これをあなたのチームに説明し、計画を立てることができます。
SlashdotのNinjaProgrammerがこの宝石を送った：
優れた設計は、貧弱なコード実装に対して回復することを忘れないでください。コード全体で良好なインタフェースと抽象概念が存在する場合、最終的な書き換えははるかに無痛になります。修正が難しい明確なコードを書くのが難しい場合は、これを引き起こしているコアデザインに何が問題なのかを検討してください。