あるソース、ソフトウェア商品の管理をしていると、プロパティという解決方法がよく出てくる。
「ここのプロパティを設定に2すると、今回上がった要望に応える事ができますが、1を設定すると既存には影響がありません。」

たいていの場合には、こんな解決方法で話し合いをしても異論がでない。

なぜなら、プロパティにより新たに状態を作成し、その状態のみに影響範囲を押さえることにより、
新規に追加したソースや、変更したソースの影響範囲を小さくするのだ。

しかし、これは非常に麻薬的効果だ。

麻薬だって適正に使う前提であれば、それが医学を大きく進歩させることもできたが、
使い方を間違えば、おかしな状態になる。

しかも、麻薬と同じく、1回の利用では問題が無くても、いつの間にか中毒になってしまうのだ。
そして、その麻薬の悪効果を抜き出すのに非常に多くの時間とコストがかかってしまう。

皆さんの周りにもそのようなシステムはないだろうか?

プロパティという麻薬の中毒度は以下のような感じで見れる。

1)プロパティにデフォルト値がない。(つまり、設定なしでは動かない)
2)カスタマイズではなく、プロパティの設定で対応可能です。の営業トークが多すぎる。
3)ユーザの為にマニュアルが書けない!と声を大きくしてアピールしている
4)関係者が、「プロパティ対応というすばらしくいい方法を見つけた!」と心酔している
5)エンジニア達がまた「それはプロパティ設定の問題だ!俺たちのバグじゃない!」などとお客からのクレームに反応している。
6)エンジニアが運用業務の情報や規模はソフトウェア構築後でも対応可能だ!と言っている。
7)高い技術の人材を投入してもあまり効果がでない。
8)妙に意味のわからない設定のドキュメントがあり、それと常ににらめっこしている気がする。
9)設定の達人なる人がいる。

こんな感じの項目に2,3当てはまりだしたら、危険になりつつある。
早急に方針の再確認をしたほうがいいだろう。

お仕事のご依頼・相談を承ります
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら

Leave a Reply

お仕事のご依頼・相談
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら
ソフトウェア&ライブラリ




ライブラリ
airxmail(en)
AIR版メール送受信ライブラリ
airxzip
AIR版ZIP圧縮・解凍ライブラリ
執筆書籍
本、雑誌等

WEB記事:CodeZine
執筆記事はこちら
カレンダー
2010年5月
« 4月   6月 »
 12
3456789
10111213141516
17181920212223
24252627282930
31  

カスタム検索
RSS
Add to Google < !–adsense–>
アーカイブ
カテゴリ
にほんブログ村 IT技術ブログへ