無駄な複雑さを制御するために、開発環境に正式な役割（内部または外部）を割り当てる必要がありますか？

数年前、私は社内のフレームワークの開発にこれまで取り組んできた小さな会社で働いていました。彼らは彼らの最上級の開発者とそのアーキテクトをカスタムMVCフレームワークとORMをゼロから開発することに専念していました。これらの2つは、コア製品と直交しています。残念ながら、このフレームワーク主導のアプローチのサポートは上から来たものであり、収益を生み出すソフトウェアの配信を遅らせました。そして、生成されたフレームワークは、既製の代替品よりも著しく劣り、遅延をさらに悪化させました。会社はすぐに現金を使い果たし、最終的には全員が解雇された。

後の雇用主も同様のミスを犯しました-彼らは非常に技術的に熟練した開発者-完璧主義者を手に入れました。このソリューションは、他の顧客に合わせて拡張することができます。プロジェクトは大幅に実行されました。しかし、他の潜在的な顧客は少しもしません。金運の戦略的失敗、それは少額の財産です。

どちらの場合も、かなりの量のオーバーエンジニアリングがありました。どちらの場合も、会社とプロジェクト管理は、プログラミングのバックグラウンドではなく、ドメインまたは分析のバックグラウンドを持つ人々でした。どちらの場合も、ソフトウェアアーキテクトは過度に複雑なソリューションを構築して、かゆみを掻き消し、履歴書を強化しました。どちらの場合も、アーキテクトはコストを抑えることに利害関係がありませんでした（会社が倒産した場合に仕事を失うリスクは別として、それは彼らの高いエンプロイアビリティを考慮するとそれほどリスクはありませんでした）。

私の経験によれば、開発ショップが陥るのは珍しいことではありません。

正式な内部または外部の技術的な敵対的な役割-「量測量者」-建物のアナロジーを使用して、無駄なオーバーエンジニアリングを呼び出したり、防止したりするためのソフトウェアプロジェクトの場所はありますか？この役割を果たすのに最適なのは誰ですか？

「複雑さの制御」は次の仕事です。

1. システムおよびエンタープライズアーキテクチャが現在のプロジェクト/製品に適していることを確認することを担当するアーキテクト。

2. 正しいだけでなく保守も可能なデザインとコードを作成し、他の開発者のコ​​ードをレビューして理解できるようにすることを担当する開発者。そして

3. ビジネス/システムアナリストまたは製品の所有者。その仕事は、ビジネスが実際に現在必要としているもの、後で完了することができるもの、またはまったく実現できないものを解明することです。

「複雑さ」はとにかく抽象的な概念であり、「複雑さを減らすこと」がそもそもソフトウェアの目的であることは間違いないので、それに専念する役割を提案することは意味がありません-それが全体ですチームはすでにやっているはずです！

ROIとTCOをざっと見てみると、ソリューションが本当に真に過剰に設計されていることが示されているとすれば、それに取り組んでいるアーキテクトと開発者およびアナリストは単にそうではなかったと申し訳ありません。彼らの仕事はとても上手です。そして、その側面を担当するのは、彼らを雇ったマネージャーまたはエグゼクティブです。おそらく、彼らはオーバーエンジニアリングの文化を育ててきており、部分的に欠陥を抱えているか、実装チームから悪いアドバイスを受けているだけかもしれません。

私はおそらく（おそらく）あなたの会社で働いていなかったので、それを推測するつもりはありませんが、1人または1人と1対1の会話をするだけでかなり簡単に理解できると思います。上記のマネージャーのいくつか。

ちなみに、社内フレームワークの開発は必ずしも悪いことではありません。これらのフレームワークは一般に、現在のプロセスの観察と改良に基づいている必要があるだけです。既存のコードをリファクタリングして作成されるフレームワークやライブラリは、長期間続く傾向があります。一方、人々が飛び込んで、まったくコンテキストのないフレームワークの開発を始めた場合、それは通常、すぐに責任となります。

人々は慣習の違いを認識できなければなりません（組織のほとんどのプロジェクトは、一定量の定型コードを使用して同じテクノロジースタックを使用しますが、それをすべて「フレームワーク」にまとめることは良いことではありませんアイデア）対複製（人々は文字どおり同じビジネスまたは技術的な問題を何度も繰り返し解決しており、その不一致は複雑な設計と深刻な欠陥につながります）。ソフトウェア企業は後者のシナリオを認識でき、またそうすべきであり、複雑さを軽減するために積極的に対策を講じます。フレームワークは、内部プラットフォームの効果に負けない限り、複雑さを軽減します。

正式な内部または外部の技術的な敵対的な役割-「量測量者」-建物のアナロジーを使用して、無駄なオーバーエンジニアリングを呼び出したり、防止したりするためのソフトウェアプロジェクトの場所はありますか？この役割を果たすのに最適なのは誰ですか？

いいえ、通常、そのような立場はありません。

コツは、仕事に適した人を雇うことです。過剰設計するつもりがなく、必要なことだけを行う人々。

これは、アジャイルアプローチを使用して行うことができます（反復で要件を実装する、TDDまたはBDDを使用するなど）。しかし、繰り返しになりますが、アーキテクチャが過度に設計されている場合、それは役に立ちません。