品質をコードに含めるのは良いことだと上司を説得するにはどうすればよいですか？
今日、上司が私のところに来て、ある機能を1.5日で実装できるかどうか尋ねてきました。私はそれを見て、2日から3日がより現実的だと彼に話しました。それから彼は私に尋ねました：「そして私たちがそれを速くて汚いとしたらどうしますか？」私は彼に「迅速かつ汚い」とはどういう意味か説明するように頼んだ。
結局のところ、彼は（たとえば）他のプロジェクトからビットやピースをコピーし、allコードを入れて、人間が可能な限り迅速にコードを記述したいと考えていますWebFormsページのコードビハインドで、DRYおよびSOLIDのこと）を気にせず、コードと機能を変更または変更する必要がないと想定します。さらに悪いことに、彼はこの1つの機能だけにそれを望まず、allのコードを記述します。
迅速かつ汚いことをすれば、より多くの利益を得ることができます。クライアントは、将来変更される可能性があることを考慮して、料金を支払う必要はありません。私たちにとっての利益は、コードを可能な限り迅速に提供することです。アプリケーションが必要なことを行う限り、コードの品質は重要ではありません。彼らはコードを見ることはありません。
私はこれがソフトウェア会社のマネージャーとして考えるのは悪い方法だと彼に納得させようとしましたが、彼は私の議論に耳を傾けませんでした：
- 開発者の動機：ずさんなコードを非常に迅速に作成するという非現実的な締め切りと予算のプレッシャーに常にさらされている場合、開発者の動機を維持するのは難しいと説明しました。
- 可読性：プロジェクトが別の開発者に渡されると、よりきれいで構造化されたコードが読みやすくなり、理解しやすくなります。
- 保守性：適切に記述されたコードを適応、拡張、または変更することは、より簡単で、安全で、時間もかかりません。
- Testability：通常は、クリーンなコードでテストしてバグを見つける方が簡単です。
上司の立場では、同僚は私と同じように困惑していますが、私たちは彼に連絡することができません。彼は、物事をより速くすることで、より多くのプロジェクトを売ることができ、より大きな利益を生み出しながら、より低い価格でそれらを求めることができると言い続けています。そして最終的に、これらのプロジェクトは開発者の給料を支払います。
彼に自分が間違っていると思わせるには、これ以上何が言えるでしょうか。 PeoplewareとThe Mythical Man-Monthのコピーを彼に購入したいのですが、彼の考えも変わらないと思います。
あなたの多くはおそらく「走る！そこから抜け出せ今！」のようなことを言うでしょう。または「私は辞めます！」ですが、.NET Web開発の仕事は私が住んでいる地域ではかなりまれなので、それは実際には選択肢ではありません...
更新
うわぁ、こんなにたくさんの回答が得られるとは思っていませんでした。あなたの貢献とあなたの意見をありがとう！
かなりの数の回答とコメントが指摘しているように、会社のタイプとプロジェクトのタイプがこのトピックで大きな役割を果たします。いくつかの回答のコメントでここでいくつかのことを説明しましたが、おそらくここにも追加する方が良いでしょう。
私が働いている会社はかなり小さいです。私たちは4人の開発者、1人のデザイナー、1人のボス、1人のすべての非技術的なトレード（ボスの妻）を抱えています。私たちが行うプロジェクトは、次の2つのカテゴリに分類できます。
- 独自のCMSまたはeコマースフレームワークで構築された小さめのウェブサイト（65％）
- 中規模のWebアプリケーション（35％）
私たちのプロジェクトの多くはかなり小規模ですが、同じシステムの上に構築されています。このシステムは約4年前のものであり、コードベースは控えめに言っても標準以下です。特定の顧客のために新しい機能を追加したり、標準の機能を変更したりすることは常に恐ろしいことです。
上司が設定した目標の1つは、製品開発に焦点を移すことです。つまり、他のプロジェクトのベースとして機能する、またはSaaSのような大きなアプリケーションを開発することになります。
物事を迅速かつ汚いものにすることが、特定のプロジェクトにとって最良の解決策になる可能性があることに、私は完全に同意します。しかし、今後数年で開発するすべてのサイトで使用される既存のCMSを拡張する場合、またはSaaS製品をゼロから構築する場合、より良いアプローチがあると思います。
申し訳ありませんが、
あなたはこれを聞きたくないでしょうが、-彼は完全に間違っているわけではありません。
あなたがコンサルタントとして外部企業の雇用のために仕事をしていて、彼らがあなたができる最も不平なことを受け入れて不満を言わないで喜んで受け入れて、あなたがより多くの仕事をするために何度も何度も何度も戻ってきてくれるなら、あなたの上司はあなたの会社の利益を最大にすることに関しては100％正しいです。
次に [〜＃〜] yagni [〜＃〜] があります。プロジェクトが1回限りのプロジェクトであり、メンテナンスや再書き込みに費用がかからず、その間ずっとメンテナンスと再作成が必要な場合-ライティングは請求可能で、それを行うright初めて実際にはさらに多くの費用がかかります。その後、あなたの上司は再び100％正解です。
クライアントがnotコストと品質の欠如について不平を言っている場合、品質はnotで問題になり、顧客を幸せにします。顧客ががらくたに満足しているように聞こえるので、彼らにもっとがらくたを売ることは難しいビジネス決定ではありません。
顧客が満足している以上のことを行うと、すべての部分で無駄な努力がなされます。彼らはそれを感謝しません。あなたの上司は再び100％正解です。
品質は見る人の目にあることを忘れないでください。それが顧客のニーズを満たしていれば、ダクトテープやコートハンガーが機能していることを気にする必要はありません。
顧客がhow気にしないため、あなたが大いに評価することは、顧客にとって直接的な価値がほとんどないかまったくありません。
すべてのソフトウェアは、最終的にはエントロピーから Big Ball of Mud に縮退します。 GUIアプリケーション、特にWindows用のアプリケーションは、ツールセットの文化により、VBエントロピーのより速いフレーバーで書かれています。
気分が良くなった場合は、他の人よりも最大エントロピーに少し近いところから始めます。
個人的に私はそのような低品質の成果物で前例を設定することは決してしませんでしたが、それでも、あなたの会社が明らかに対応しようとしている顧客のレベル底辺までの競争には行きません。
あなたの経営陣は、これらが彼らが望む顧客であり、しようとする必要がないと決定しましたアップセル彼らが物事の状態に問題がない場合、より高価なより高品質のソフトウェアの顧客。
あなたは経営陣に変化をもたらすつもりはありません、あなたの顧客だけがそれをするでしょう。あなたはより良い顧客を得るか、より良い仕事を得ることができます。
私の古い仕事のように聞こえる
これはいつも私の古い仕事で起こりました。売上高がすべてを動かすことに同意します。ショップマネージャー（スキルセット：80％営業20％グラフィック）は、顧客が望む機能を常に過小評価していた。 20時間の仕事は10時間の価格で販売されます。これは、顧客がこれ以上支払う意思がないか、または（私は考えがちですが）セールスマネージャーが十分に強調していなかったためですThe Value顧客は取得。
多くの場合、セールスマネージャーは、さまざまな顧客向けに構築した見込み客の機能とウィジェットを表示します。そしてもちろん、彼はこの機能を新しい見込み客に売り込みます私たちは本当に再コーディングする必要がなかったので...コードをコピーして貼り付けるだけで済みました別のウェブサイトからこのサイトにプロップします。すでに作成しました。
「なぜこれをより速く行うことができないのか...顧客xのためにすでにそれを行った」という何度も叫んだセッションの後。そして、「顧客yに10時間しかかからなかったのに、顧客zに16時間かかったのです」。
営業担当者に目的は何ですか？彼はできる限り多くのウィジェットをできるだけ安い価格で販売すると述べた。
私たちは質の高いショップであり、質の高い仕事をしていると彼に伝えました。価格を下げることで、実際に私たちの仕事の価値を薄めていることを伝え、以前開発されていなかった新機能のために顧客が私たちに戻ってきたとき（サイトxからコピーして貼り付けるオプションは意味しなかった）そこにはありません）彼らは価格設定を押し戻し、セールスマネージャーはプレッシャーの下で座屈するでしょう。
私たちはウィジェットをそのままプレミアム価格で価格設定することにしました。変更は余分になります。これらのウィジェットを開発して、他のWebサイトからではなく "Code Library"からプルできるように時間を与えれば、より一般的な方法でそれらを構築して、文字通りプロップできると経営陣は確信しました。 2時間で既存のサイトにアクセスし、10時間の支払いを受けます。
彼は「現状のまま」の改造のプレミアム料金でそれらを販売し始めました、そして我々はそれらを入れて、それらを２時間で働かせることができました。また、これらのウィジェットを "Our Website"に追加し始め、他の顧客のWebサイトを販売ツールとして使用することをやめました。他の顧客のWebサイトのみを使用して、ウィジェットをカスタマイズして "for a little fee"をこのように機能させる方法を示します。
私たちのコンセプトを証明するために、私たち（開発者）は、仕事の後数晩遅く、コードライブラリに汎用ウィジェットを作成するためにそれを構築しました。人生は良くなりました。 「ねえ、お客様xが望むこのウィジェットを転売できますか？もしそうなら、どんな機能を追加したいですか？」あなたがそれを販売するのに役立つ基本的なモデル。 "
企業がこれを行うのを見てきました。彼らは怒った顧客になってしまいます。アプリが収益を上げ始めるか、ビジネスフローに統合されるとすぐに、顧客は戻ってきて新しい機能を求める傾向があります。コードベースを処理できなくなったため、作成した混乱に新しい機能を追加できないことを、すぐにそれらの顧客に伝える必要があります。それとももっと時間がかかります。
顧客は（互いに競争的な状況にあっても）話しがちです。直接、または従業員が会社を切り替えることによって、または彼らの基幹業務（会議、展示会）に典型的なイベントでのランダムな会議によって。会社の評判が悪いと、すぐに新しい顧客を獲得するのが難しくなります。
さらに、低品質のコーディングは、会社が非常に小さなプロジェクトに限定されている場合にのみ（もしあれば）機能します。それよりも大きく複雑なものは、プロジェクトの最初のライブサイクル内であっても、見積もりよりもデバッグに多くの時間を費やすだけで、即座に時間（およびお金）を失います。
技術的負債について彼に教える
あなたがしなければならないことは、彼がする選択の結果を彼に理解させることです。物事をより早く終わらせることができるので、速くて汚いことは大丈夫ですが、長期的な影響があります。
たとえば、プロジェクトが大規模なコードベースを持つことを意図していない場合、迅速かつダーティな方法がそのプロジェクトを処理する完全に正しい方法である可能性があります。
ワード・カニンガムは、「技術的負債」という見事な比喩を思いついた。あなたが何かをより速くするために銀行でローンを取るかもしれないのと同じように（貯蓄するのではなく）、利息を払わなければならないので、長期的にはより多くを支払わなければなりません。あなたの「もの」をより速くすることの価値が興味のコストを上回っているならば、これは良いことであるかもしれません。
迅速で汚れたソリューションは、銀行のローンのようなものです。繰り返しになりますが、機能を早期に取得することの価値がその後のクリーンアップのコストを上回る場合は、ローンをとることが正しいアプローチになる可能性があります。
しかし、あなたが銀行でますます多くのローンをとるならば、結局、あなたは興味のあるすべての収入を支払います。技術的負債と同じです。あなたがあまりにも多くの迅速で汚い解決策を作ったなら、あなたの技術的負債は非常に高くなり、あなたの進歩は深刻な停止に至るでしょう。
私はこれが起こるのを見てきました。私が取り組んだ1つのプロジェクトでは、技術的な負債が非常に大きかったため、3か月間真剣に進歩せず、バグを修正しようとしただけで、新しいバグなどが導入されました。
彼に技術的負債の概念を完全に理解させることができれば、彼は正しい決定をすることができるはずです（幸運、それは難しいです）。正しい解決策は、時として迅速で汚いことも意味することに注意してください。
あなたが指摘するかもしれない最後の1つは、彼らが非常にやる気があるならば、開発者はより生産的であることです;）
maintenance のコストは、多くの場合、はるかに高く、多くの場合、ソフトウェアのコストの大部分です。
迅速かつダーティなプログラミングを行うと、メンテナンスが桁違いに難しくなり、コストも高くなります。
すべてのソフトウェアを迅速かつダーティに構築すると、それは安っぽくバギーになり、クライアントはそれに気づくでしょう。長期的に見れば、製品が不安定でバギーであり続けると、製品を失うことになります。クライアントは、あなたのバグに苦しむよりも、良質の製品に対してもう少し多くを競合他社に支払うことを望みます。
上司はこれを理解していませんか？
最もまれなケースを除いて、あなたはcannotは、めちゃくちゃ近視の人に、私たちの仕事ではほとんどの場合より長いことを説得します。申し訳ありませんが、それは真実です。近視眼的な人々は今すぐにすべてを犠牲にして利益を享受し、ほとんどの場合結局は苦しみます。
時には正しい解決策isは、人々が品質の利点を理解するのに十分賢く、近視ではない場所に位置を変更することです。
注：この回答は、理由を使用して全員が確実に期待どおりのものを得ているようにするビジネスコミュニケーション戦略を取ります。問題が単に低品質のエンジニアリングを行うことが生きる意欲を低下させていること、または上司が奴隷の運転手であり、終わりが見えないように見える場合は、実際には風景を変える時が来ているかもしれません。
あなたは上司の言葉を話していません。あなたの仕事の一部は、上司に決定を下すことができるように上司に情報を提供することであり、情報提供戦略を変更する必要があります。あなたはエンジニアリングの話をしていて、彼が聞く必要があるのはリスク、コスト、投資、そしてリターンです。また、少し防御的である必要がありますそして、あなたが彼に何を通知したかについての良い記録があることを確認してください。
これには2つの部分があります。
1つ目は、見積もりと、それが目標や計画ではないという考えを伝えることです。ここにボリュームを書き込むこともできますが、基本的には、McConnellの " Software Estimation：Demystifying the Black Art "のすべてのコピーであり、本を歩くのではなく、実行する必要のある本です。見積もり、目標、およびコミットメントを区別するように注意し、何かにコミットする前に実際の見積もりを行ってください。
2つ目は、上司が関心を持っている実際のリスクの伝達です。簡単に言えば、1.5日で完了する可能性のある実装は基本的な要件を満たしますが、将来の変更や機能が必要と思われるよりもはるかに多くの時間を必要とするリスクを大幅に増やします。彼が理由を尋ねる場合は、住宅建設の類推を使用してください。ソフトウェアが住宅である場合、すべての変更は新しい家具であり、すべての機能は新しいフロアです。強力な基盤がなく、何かをするたびに少しずつ改造/改修すると、最終的には、大きな窓の改造が新しいウィンドウトリートメントの重量とサイズをサポートするためだけに必要になる状況になります。また、4つの新しいフロアと1つのデッキをサポートする場合は、家全体を再構築する必要があります。
これはあなたのボスのコートにボールを戻します-あなたは彼に情報を与えました、そして彼は決定する必要があります。彼は将来の変更があるかどうか、そしてその可能性を無視したいかどうかを考える必要があります。そこから、高速で低品質の方法が決定した場合は、その意思決定について（事実上）通知を行い、可能な限りすべてのコミュニケーションとドキュメントにそのことを通知してください。意思決定とあなたが伝えたリスクを確認するフォローアップメールを送信し、それを文書に書きます。エンジニアリング戦略と仕様のリスクについて書き留めます。
お客様が50階にプールを設置したいという日が来て、最後の20階が棒と砂で建てられていることがわかったら、そのために作成した大きな脂肪の見積もりが技術的に正当であり、準備ができていることを確認してください。低入札の請求書の紙の証跡を展開して、なぜそれがそんなに高くつくのかを説明します。
あなたが本当にこれらすべての議論をし、彼がまだそれらを払いのけているなら、この懸念をより高いインスタンスに提起することは専門家としてのあなたの義務です。はい、それは彼の頭を越えることを意味します。その理由は、単にあなたの上司が会社にとって危険だからです。
これらの人との私の経験は、彼らが最終的にあなたの組織を失敗または少なくとも平凡に追いやることです。あなたの製品は吸うでしょう、そしてあなたの顧客はあなたを離れます。
記録のために：私は、組織のコアビジネスがソフトウェア開発であり、製品が重要であり、捨てるものではないと想定しています。
W。エドワーズデミング は、第二次世界大戦後の日本の製造業の再構築における彼の業績で最もよく知られています。しばしば見落とされているのは、彼の仕事が実際には製造よりも管理にあるという事実です。実際、彼の本の主要なセクションOut of the Crisisは、サービス組織の質の向上についてです。彼のサービス組織の例には、ソフトウェア、銀行、保険、教会などがあります。
デミングは、それを裏付ける多くの現実の証拠を用いて、品質の向上が利益を増加させると主張しています。
ソフトウェア開発をビジネスプロセスとして分析できます。製造と同様に、意図的、非意図的、直接的、および間接的な製品を生産します。
製造とプログラミングの意図的な直接製品には、蛇口とソースコードが含まれます。意図的な間接商品には、負債と所得が含まれます。
製造プロセスの意図しない製品には、製造上の欠陥、偶発的な火災、けが、高い離職率、従業員の盗難がある蛇口が含まれます。プログラミングプロセスの意図しない製品には、バグ、メンテナンスの問題、スケーラビリティの問題、セキュリティの問題、スタッフの離職率の高さ、従業員の盗難などがあります。
これらの「製品」はすべて、ばらつき、統計分析、およびプロセス改善の対象となります。
あなたのケースでは、おそらく、ソフトウェア開発とプロジェクト管理プロセスの意図しない製品を列挙して定量化する必要があります。
デミングは、日本が世界の製造業の大国である主な理由の1つです。デミング賞は彼にちなんで名付けられました。
はい、それを今日一緒にハックすることができます。
そのようにすると、平均よりも多くのバグが発生し、将来の開発が大幅に後退します。これを一緒にハッキングすることは、実際には1回または2回行うことができます。スカイスクレイパーと考えてください。すでに素敵な土台があるかもしれません。10フロアも本当に素敵です。必要に応じて、テントやボックスを11階にすばやくたたくことができます。 12階はテントや箱から出ていますが、それ以上に行くのは面倒です。 13階に移動するには、2階から全員を移動させてセットアップし、すべてを再トレーニングして、もう一度構築する必要があります。
ボックスとテントで13階を建てようとすると、ランダムに3階が崩れる可能性があり、適切な場所にジェンガブロックと超接着デュプロを配置するのに数か月かかる場合があります。
これは受け入れられますか？
あなたの上司は正しいかもしれません。このタイプのコーディングで十分なシナリオを考えることができます。ある種のデータ分析用の使い捨てのスクリプトや、ほんの数ページを見て何が起こっているのかを知ることができるおかしなWebサイトを作成するとします。これらのタイプのものは維持される可能性が低いため、過剰設計する必要はありません。それが私たちがクライアントが望むものであれば、それがクライアントが得るものです。
さて、それはあなたの上司が間違っていることも非常によくあるかもしれません、そしてクライアントは不十分に機能している製品を評価しないでしょう。これはほとんどの場合です。
それはまたある種の幸せな媒体を思い付くためのオプションかもしれません。主なことは、何かが機能していない場合、変更する必要があるということです。上司は明らかに、開発プロセスがビジネスにどのように影響しているかに満足していません。製品化までの時間は、製品の品質と同じくらい重要です。あなたがする必要があるのは、あなたのチームが製品の市場性を損なうことのないタイムフレームで高品質の製品を生産できるようにすることです。エンジニアリングの原則が正しく使用されていれば、チームの生産性が損なわれることはありません。どちらかといえば、健全な慣行を使用すると、開発プロセスがスピードアップし、品質が向上するはずです。
それは可能ではないと思います。企業によって文化は異なりますが、現在の企業の文化（迅速で汚い）があなたに合わない場合は、先に進むべきだと思います。他のいくつかの会社は反対の見方をしており、そこであなたはあなたと同じように考える人々と協力するでしょう。
私は本当にどのような文化が良いかについての議論には入りたくありません（興味があれば他の投稿を参照してください）。アプローチ。
私はすべての質問に目を通し、誰もセキュリティの観点に行っていないことを確認しました...
はい、他の人はデバッグ時間について言及しましたが、この場合のデバッグは「やっとうまくいく」レベルまでしか行われません
私のプロジェクト（小規模および/または大規模）では、悪用やセキュリティホールの可能性に高いレベルの注意を払っています。
これらを考慮に入れてテストするのにはかなりの時間がかかりますが、少なくともこのようにすると、何か悪いことが起こったときに最善を尽くすと非難されることはありません。
変数をサニタイズすることを忘れてしまいがちな場合は、関数のチェックを忘れて、ハッカーがプロジェクトを始めるのに最適なポイントにしてください。
上司が何かにそんなに時間がかかった理由を尋ねたら、私が組み込んだすべてのセキュリティと機能チェックを示し、インジェクション、インクルージョン、無限ループ、さらには何かがハッキングされたときのセキュリティ対策でさえ、最小限のダメージしか与えないようにします
これは当たり前のように思えるかもしれませんが、私はあなたが中道を見つける必要があると思います。あなたの上司の態度を手に負えないほど軽視しないでください。それについてのあなたの見解は、彼にとってあなたと同じようにおそらく彼にとって異質なものです。
どちらの極限も明らかに誰にとっても良くないので、中立的な立場で交渉してみてください。
彼に数学を投げなさい。残念ながら、私は手元に引用を提供するための本を持っていません（うまくいけば誰かが私を助けてくれるでしょう）が、Pragmatic ProgrammerとCode Complete 2のどちらかまたは両方には、物事をすばやく行うことのコストへの影響を示す研究を参照するセクションがあります'n'汚い方法ではなく、後で修正するために時間をかけます。他のポスターは多くの箇条書きの議論を提供しましたが、あなたの上司の態度によっては、彼は既存の研究からのサポートにはるかによく反応するかもしれません。彼はあなたがあなたの時間をバッファリングし、あなた自身のワークロードを楽にするためにただ怒っていると思うかもしれません。あなたの意見だけではなく、業界で認められた事実であることを彼に示すことは、チケットかもしれません。
私はどういうわけかあなたと同じような状況にいます。私はサービス会社で働いているので、さまざまなクライアント用のカスタムアプリケーションを作成しています。アプリケーションの提供を担当する人々（プロジェクトマネージャー、プロジェクトエグゼクティブなど）は、実際にはコードの品質には関心がありません（そうは言っていますが）。利益。私は常に短期間で機能を作成するように求められます。
期限を守りながらコードの品質を維持するために私が使用した手法は、継続的なリファクタリングです。機能Aを1日で書くように頼まれた場合、実際には高品質で書くのに3〜5日かかりますが、私は迅速で汚い方法を実行して配信します。しかし、迅速かつ汚い方法を実行している間、私は改善できる/すべき領域についてメモをとっています。その後、開発サイクルの後半で、あちこちに時間の断片を見つけて、機能Aのコードをリファクタリングします。
最初は、私の迅速で汚いコードをリファクタリングするのは面倒な経験でした。リファクタリング中に機能をほぼ完全に書き換えた例をいくつか覚えています。しかし、ますますリファクタリングを行うにつれて、私の迅速で汚れたコードはそれほど汚れていなくなりました。私はモジュール設計のより自然な感覚を開発し始めたので、私が書いたコードは、クイックモードとダーティモードのどちらでも、ますますモジュール化されます。
多くの人にとってそれは実際には重要ではないので、コードの品質が重要ではないと考えるのは間違いではありません。ソニーのTV内の回路の設計品質に本当に気を配っていますか？
ただし、開発者としては、その利点を知っているので、コードの品質に本当に注意する必要があります。あなたの上司は、コードの質が彼の日を救ういくつかの危機を経験しない限り、または彼が個人的に利益とコードの質の間の相関関係を見たときに、コードの質について彼の考えを変えることはほとんどありません。
上司がコード品質に関する知識を欠いているからといって、コード品質を妥協する必要があるわけではありません（ただし、コード品質について上司との通信チャネルを開いたままにしておくことをお勧めします）。コードの品質と開発スケジュールのバランスポイントを見つけるよう努めます。現在のスケジュールで良質のコードを記述できないからといって、将来のスケジュールで品質を改善できないということではありませんか？
物事を速くて汚いことをすると、昼食前であってもあなたを遅くすることができます。多くの場合、機能を完成させてクライアントに受け入れてもらえるようになる前でも、害を及ぼし始めます。
多分あなたは技術的な負債のメタファーを試すことができます、利息支払いの負担はある時点の後に収入より大きくなります。
書き換えに向けたステアリングは、顧客が別の開発会社を試す機会でもあります（ゼロから始める場合も同様です）。
お住まいの地域に代替の雇用主がいない場合は、さらに多くの顧客が身に着けている可能性があります。したがって、基本的には、上司は彼がやっていることをやり続けることができます。おそらくあなた自身のビジネスを始めますか？ ;-)
あるいは、常に「素早い、汚い」ことをして自分でやることを彼に言うだけでもいいでしょう。
最良の答えは、アジャイルアプローチからです。
早期リリース、頻繁リリース
早期リリースは、早期に支払いを受け取るようになるため、会社に適しています。最初のリリースポイントは、製品が十分な機能を備え、少なくともある側面で使用できるようになるときです。したがって、クライアント企業の価値を高めます。そのため、モジュールごとに開発するのが賢明です。
頻繁にリリースするは、クライアントがすぐに何を手に入れるかを知るのに適しています必要。最終結果が最初のアイデアと頻繁に異なるので、私は意図的に欲求を書きませんでした。
他に何もなければ、これはクライアントがより関与していると感じ、あなたはあなたの製品を段階的に反復するので、クライアントをより満足させるでしょう。
この場合は何も言えないという気持ちが強いです。しかし、私が提起するいくつかのポイント：
問題の修正に時間がかかる
すべての場所にコードをコピーして貼り付けた場合、そのコードにバグが見つかった場合は修正に時間がかかり、テストに時間がかかります。したがって、サポートフェーズで余分な時間を無駄にすることになります（私は、「ドアを開ける」という考え方を備えた統合テストフェーズがないと思います）。
新しい機能の追加には時間がかかります
スパゲッティコードに新しい機能を追加するには、かなり時間がかかります。そして、それはコピーアンドペーストの混乱であるため、多くの場所でコードを微調整する必要があります。これにより、さまざまな場所でバグや予期しない機能が発生します。したがって、サポートフェーズで余分な時間を無駄にする必要があります。
新規クライアントのスキニングUI要素と用語に時間がかかる
現在私が働いている会社彼らのWebクライアントは、スパゲッティコードのコピーアンドペーストの混乱から始まりました。始める前に、新しい顧客のためにWebクライアントのスキンを作成するのに2週間かかりました。
数夜の長い夜を経て、今では午後になりました。私はまだ作業していて、時間がかからないように調整しています。
上司が販売しやすい製品をさまざまな顧客に提供したい場合、上司は時間を投資して、新機能を販売できるときに製品のスキンを作成する時間を無駄にしないようにする必要があります。
それは難しいことですが、上手く理解して、正しく実行するために今しばらく時間を費やさない限り、将来、バグに多くの時間を費やし、実際に製品を入手するのに時間がかかることになります。将来の新しいクライアントの準備ができています。
彼が気にしているのは一番下の行だけなので、この方法でコーディングしても効果がなく、妨げになるだけであることを理解させる必要があります。