ソフトウェア開発における最悪の偽経済とは何ですか?[閉まっている]


126

ソフトウェア業界で流行している最悪の偽りの経済(それは最終的に貯蓄以上の費用がかかるお金を節約する方法)とは何ですか?


2
:(これらの多くを頻繁に見
トニー


@Casey:少し関連していますが、完全ではありません。あなたが与えたリンクはお金を直接扱っていますが、この質問の答えはお金と信念も扱っています。例、私の答えを参照してください:Programmers.stackexchange.com/questions/19573/…–
Gan

あなたはちょうど私の会社を訪問しました。.気にしない; P
pramodc84

1
@Mark-いい質問ですね。しかし、さらにいくつかの詳細が良いかもしれません。
ジョンホプキンス

回答:


182

技術債務

すなわち、「すぐにそれを行うだけで、後でリファクタリングします」。第一に、この動作に関与している誰かが実際に後でリファクタリングするのをまだ見ていないからです。第二に、良い方法の代わりに迅速に物事を行うと、将来の機能を追加したり、将来のバグを解決することが難しくなり、最終的には時間を無駄にすることになります。

悲しいことに、多くの人は、開発者のサイクルを節約して、何かを高速に実行できると考えています。可能だと思いますが、実際にはまだ見ていません。


2
1日に管理者が開発者を停止した回数(2〜3回)を数えられません。その後、展開スペシャリストが何かをクラッシュ修正します(そして、製品のライフサイクル中にこれを何度も繰り返します)。正しく行うには4日間。素晴らしい答え。
DevSolo

4
株式取引システムのバグ修正など、修正にかかる時間がドル単位で測定可能な場合、管理上の決定はコスト削減に傾くでしょう。「これを二度と起こさないように正しい修正を決定する間、それを実行し続けるために今すぐパッチを適用する」という提案は、コスト主導の緊急性を満たし、正しい結果を得ることができますが、あなたはこのために戦わなければなりません。
JBRウィルキンソン

9
「これはハックです。デモの後に置き換えてください」のようなコメントがコード全体にありますが、これは3〜5年続いているベースです。この時点でそれが行われたことを誰も覚えていないので、誰か(私)がバグを修正してそれを実行するまで、誰もそれを見つけません。言うまでもなく、このオブジェクトレッスンは、私が何らかの方法でそうすることができるなら、最初に正しく行うことを非常によく教えてくれました。
CodexArcanum

22
そして、正直なところ、短期間の時間が節約されない回数に絶えずショックを受けています!
PeterAllenWebb

6
@Jorg-え?「技術的負債と設計上の負債は、slapdashソフトウェアアーキテクチャと性急なソフトウェア開発の最終的な結果を指す同義語であり、ネオロジカルなメタファーです。」en.wikipedia.org/wiki/Technical_debtこれはまさに私が言及しているものです。より具体的なタイトルは、おそらくしかし、このような状況では多くの人々は、彼らが実際に返済するつもり(ないが)ない自分自身を伝える、「それを返済する意思がなければ被ら技術的負債」されているだろう、と私は望んでいたパンチの効いたで置くためにタイトルを上部の太字のテキスト。「技術的負債」は十分な要約であると思われた。
イナイマティ

163

本当に素晴らしい1人ではなく2人の安い開発者を雇う。(同じ価格で)


9
これは少なくとも現実には根拠があるようです。技術に詳しくない人は、優れた開発者が誰なのかわからないことに注意してください(したがって、実際のスーパースターよりもランダムなコンサルティング馬鹿に2倍の金額を支払う可能性が非常に高いです)。
イナイマティ

112
または悲しいことに、1つだけ安いものを雇う
...-DevSolo

4
...または、2人のダミーがグルの給与の1.0に対してグルが行うことの1.5を行うグルを雇う:/
bobah

14
ダミーから教祖の75%を取得することはできません。本当に優れたプログラマーであれば、それについて気に入らずに必要なことを行います。
ピーターボートン

8
10倍または100倍のプログラマーは、このような信じられないほどのお金の価値です。彼らはたぶん1.5倍の2倍しか支払われません。Michael Lopp(Rands in Repose)が言っているように、あなたがキャリア全体でこれらの1つだけを雇うなら、それは正味の勝利です。
ティムウィリスクロフト

85

私の例は、NimChimpskyの例の完全な反対、つまり:

市販品を社内で開発しようとしています。

通常、これは実際に市場をチェックして問題を解決するものが既に存在するかどうかを確認できないために生じます。これは、研究を行う前にコーディングに「飛び込む」ことを好む開発者や、その時間=お金を考慮に入れないプロジェクトマネージャーによってさらに悪化する可能性があります。

私の分野で見た最も一般的な例の1つであるWeb開発は、CMSシステムを開発しようとしている企業です。これらは常に小さなものから始まりますが、機能がボルトで固定されるとすぐに肥大化して制御不能になります。その一方で、より適切な無料の製品とフレームワークが常にたくさんあります。


17
それができるからといって、そうあるべきという意味ではありません。基本的なCMSで、なぜそうなるのでしょうか。しかし、大規模システムの話を始め、複雑なビジネスプロセスのモデリングを始めるとき、なぜ丸穴を四角い穴に収めようとするのでしょうか?特に、既存の開発者とスキルを社内に持っている場合。
ニムチンプスキー

9
@NimChimpsky-両方の有効な例があると思います。私は確かに人々が彼らのビジネスプロセスを壊し、既製のソフトウェアに合わせようとすることで彼らが持っていた利点を失うのを見ましたが、彼らにとってはもっと面白かったです。
ジョンホプキンス

3
@NimChimpsky仕様が特注の開発を必要とする場合、それは問題ありません-それは仕事で私たちを維持します:)問題は、人々が最初に法案に合う開発済みのものがすでにあるかどうかを最初に確認しないときに発生します。少しの研究は大いに役立つでしょう!
ダン・ディプロ

6
なぜ車輪を再発明するのですか?あなたはホイールエンジニアだからです。または、あなたのホイールが次の男のホイールよりも優れているからです。または、ホイールが合わないため。参照:mostlymaths.net/2010/03/…–
デレク

2
私はほとんど仕事どこですべてが私たちの大胆不敵なリーダー(TM)によると、「私たちの環境はほど複雑であるため、ほぼすべてが、社内で再考案された- OTSを購入することができ、何も市場に出回っているが、可能性があり、おそらくそれを処理しません」。うん!しかし、なんと-それは手形を支払う。昨日、私たちのソフトウェアの主要なコンポーネントが来年、グラフィックインターフェイスで書き直されると言われました!ああああああ!私はすべてa-twitterです...(<pheh!>)
ボブ・ジャービス

73

プロジェクト管理専用のリソースはありません

数人のプログラマーが契約したときに何度か経験しましたが、すでに日課が厳しい人はプロジェクトを管理すべきでしたが、実際には他のタスクで忙しすぎたため、プロジェクトは勢いを増しませんでした。プログラマーは「プロトタイプ」などを作成しましたが、リードがなければ、その多くは忙しく見えるように輪になって実行されていました。

新しいプログラマーのための悪い装備

私はかつて、「新しいプログラマーは、ふさわしいと証明されるまで、小さな画面の本当に古いPCで作業しなければならない」という方針を経験したことがあります。そのような政策がネガティブな選択を引き起こし、常により健全な環境で働く選択を常にしている善良な人々を追い払ったことは驚きではありません。


19
+1。従業員に適切な機器を提供しないと、「失敗する」ことになります。
テレンスポンス

3
+1。ただし、次の点に注意してください。多くの企業では、ハードウェア予算はインフラストラクチャに該当し、開発予算とは別にされています。インフラストラクチャマネージャーは、開発マネージャーの予算を軽減するために自分の予算に打撃を与えることはありません。私はこの厄介な政治が何度もプレイするのを見てきました。
フィル

3
すべてのプログラマーにとって悪い機器はどうですか?私の元雇用者は、5年前に平凡だったデスクトップ上でコードを書くためにシリコンバレーの賃金を支払いました。締め切りが厳しかったため、彼らは1年前にスタッフの半分を解雇し、残りのほとんどは7月に解雇しました。
ボブマーフィー

1
Kaz:すべての開発者には適切なマシンが必要です。新しいハードウェアを購入するということは、新しい開発者のPCが他の開発者のPCよりも少し優れていることを意味します。普通の人は、彼らが効率的に仕事をすることができる装備を持っている限り、単に気にしません。私が現在働いている場所では、私を雇った人よりも新しい(おそらくより速い)PCを持っています。私の後に来た人たちは、より新しい、おそらくより高速なPCを持っています。何だと思う?マシンはすべて十分に高速であるため、誰も気にしません。
user281377

3
ハードウェアが不十分な場合、通常、足の爪を切り取ったり、長時間のコンパイル中に論文を読んだりするなどの有用な作業を行うことで、管理者に知らせます。古い低速のマシンを取得しますか?確かに、問題ありません。ああ、あなたは急いでバグを修正しました、そして私はビルドをしなければなりませんか?確かに、Mr-bwana-sahib-dude-90分で会いましょう!(マネージャーが私に一日中やったことを尋ねたら、「アプリを再構築しました。4回」と言いました。「8時間以内に!??」と叫びました。 10時間かかりました」。新しいマシンはすぐに現れました... :
ボブジャービス

71

プログラマーをテスター/テクニカルライターとして兼任させることで費用を節約できます

テスター/テクニカルライターの仕事にプログラマーの給与を支払っている場合、お金を無駄にし、その仕事に自分のキャリアを捧げている人よりも質の低い仕事を得ている可能性があります。また、プログラマーが厳しい締め切りテストに直面している場合、ドキュメントはそれを満たすために途中でやめられたり、やめられたりする可能性が非常に高いです。

ところで:開発者は常に厳しい締め切りに直面しています。


12
頭のいい人は、何でもうまくやることができます。
ジョンホプキンス

3
データ入力は完了しましたが、料金を引き下げるつもりはありませんでした。重要なデータ入力に対して迅速かつ正確な人を望んでおり、少なくとも3倍のデータ入力料金を払ってもかまいません。彼らの選択。
デビッドソーンリー

1
コードをテストするのはプログラマーの仕事だと主張しますが、それがあなたが参照しているものかどうかはわかりません。
ベンレイキー

3
プログラマは、ソフトウェアを破壊する専門家である専用のテスターを排除するのではなく、独自のコードをテストする必要があります。
JohnFx

1
テクニカルライティングについて同意し、テストについて同意しません。テストは、優れたソフトウェアを作成するための自然な部分です。テクニカルライティングは、コーディングからの移行にすぎません。コーディングからテクニカルライティングに移行するために多くのギアを変更する必要があり、自分の時間をうまく使っていないように感じます。
アダムブルース

63

製品開発に関係しないコードの調査/読み取り/作成はリソースの無駄です。

一部のプログラマーやマネージャーでさえ、それを信じています。通常、彼らは頭の中の知識に基づいてプログラミングを行い、問題に直面したときに調査を行い、答えを探します。積極的に知識を継続的に改善することはありません。私の意見では、常に最新の状態に保つ必要があり、収集した知識は既存および将来の問題を解決するのに役立ちます。もちろん、そうするために時間を賢く割り当てる必要があります。

これもダンの答えに似ています。一部のマネージャーは、開発者が市場にある既存の製品を調査せずに、要件に応じて製品にすばやく飛び込み、開発することを望んでいます。


3
これを複数回支持できたらいいのにと思います。
MAK

1
GUIライブラリを書きましょう。メッセージングツールキットを構築しましょう。あなたがソフトウェアの一部を売らないならば、それはより大きなものの一部に過ぎません、天国のためにただ誰かの実装を使用してください。オープンソースソリューションを使用する場合の安全ポイント。必要に応じていつでも修正およびサポートできます。ソースが含まれているソリューションを購入するお金がある場合は、そうしますが、市販のソフトウェアコンポーネントの品質が悪いことに注意してください。ベンダーがコンポーネントを2度販売することはめったにないので、一度所有すると失望するかもしれません(以前に噛まれた場所で働いたことがあることを知っています)
ティムウィリスクロフト

58

多くの場合、オフショアリングにはさらに費用がかかります。私の会社では、新しい従業員のスロットを取得するのは非常に困難です。また、現場の請負業者を獲得するのも難しい。オフショアとオンショアの3:1の比率が維持されるはずです。その結果、多くのチームがオフショアを数十社雇って、ほとんど使用せず、4人のオンサイト請負業者を獲得できるようにしています。


18
+1。オフショアリングでの私の経験は、必然的に節約するよりもかなり多くのお金がかかることです。
アダムクロスランド

2
+1、ただしオフショアは正しく使用すれば

3
+1。新しいプロジェクトごとに異なるオフショア開発者を獲得しているようです。つまり、オンショア開発者は、ほとんどの時間を新しいオフショア開発者に技術的サポートに加えてビジネスおよび技術ドメインモデルを教えることに費やしています。プロジェクトが終了すると、彼らはどこかへ行ってしまい、次の「安い」開発者のセットからやり直します。
クリスナイト

8
多くのチームが1ダースをオフショアで雇い、ほとんど使用していないため、4人の現場請負業者を確保できます。ワオ。
-poolie

1
そして、オフショアリングはそれ自体がデッドラインを延長することを忘れてしまいます。オフショアQAがあり、同じオフィスのtwpの人々が時差のために1時間以内に回復できるものを再愛用するには、3〜4日かかります。
HLGEM

50

長いフィードバックループ!

それはすべての人に起こります:あなたは素晴らしいと思う何かを構築し、あなたは間違っていたことがわかります。それは問題ではありません。問題は停止する必要があると判断する前に構築に費やす時間です。

高レベルでは、この問題は長いリリースサイクルで見られます。フィードバックなしで1年間ビルドすると、1年全体でギャンブルをしていることになります。頻繁にリリースすればするほど、ギャンブルは小さくなり、ギャンブルが上手になります。

しかし、それは最低レベルでも起こります。開発者として、コードレビュー(またはペアプログラミング)が頻繁に好きです。誰かが「ちょっと、もっと簡単な方法があります!」同じ理由で、ユニットテストを迅速かつ頻繁に実行するのが好きなので、バグが成長する前にキャッチして殺すことができます。

短いフィードバックループの重要性に気づき始めると、どこにでもそれが表示されます。たとえば、OODAループの軍事概念。


6
+1。また、フィードバックループが長ければ長いほど、タスクに関する記憶が少なくなります。極端な場合は、コードベース全体をもう一度やり直す必要があります。
ジョセフタネンバウム

虚偽の経済はどうですか?節約の目的は何ですか?
クリスピットマン

目的は、すべてのループを実行することで「無駄」になる時間を節約することです。たとえば、構築、テスト、リリース、ユーザーへの注意。とにかく、それは言い訳です。それは本当に不快感の回避に根ざしていると思います。
ウィリアムピエトリ

これが、レビュアーとペアの仲間がコーダーをできる限り謙虚に尊敬することが不可欠である理由です。コーダーの扱いが不十分で、フィードバックループが大きく成長することを保証できる面倒なレビューアー。
ジョナサンノイフェルド

47

私自身の逸話ではありませんが、無料のコーヒーを開発者に提供しなくなったお店を聞いたことがあります。それぞれの方法で旅行します)、いくつか購入します。

ほぼ偽経済の定義。


4
それはかなり特別です。外出してコーヒーを飲むのにかかる時間をなくすために、建物に補助金付きのスターバックスが建てられたロンドンの商人銀行のいくつかと比較してください。
ジョンホプキンス

48
これは自動的に誤った経済であることに同意しません。コーヒーを購入するために外に出て行く10分間の新鮮な空気は、従業員に酸素を供給し、集中力を向上させます。コーヒーが無料でないためにコーヒーを手に入れない従業員は、時間通りに家に帰り、より多くの睡眠を取り、カフェイン摂取量が減少するため、より健康になります。
JBRウィルキンソン

6
-1、20分間の散歩は心を解放し、問題に対する新たな視点を得るのに最適です。
マルフィスト

23
@Malfist:私が理解したように、それは20分歩くだけでなく、実際に仕事を中断したコーヒーを得るために15分待つことでもありました。1日の任意の時点で45分間休憩すると、1時間半をはるかに超えて生産性がほとんど失われます。コーヒーで月100ドルを節約できます。
EricBoersma

8
20 + 15 = 35 [さらに6文字]
マルフィスト

47

2台目のモニターは高価すぎるため、単一画面のワークステーションを提供します。毎年1時間の作業しか節約できないとしても、2番目の画面は依然として良い投資です。私のおかげで、多くの時間を節約できたことは確かです。

マルチモニターのセットアップは、開発タスクだけでなく、ほとんどすべてのタスクをより効率的にすることができます。2台よりも3台のモニターの方が優れていますが、余分な画面があるたびに効果が顕著になりません。

マルチモニターのセットアップ:

  • ウィンドウ切り替えのオーバーヘッドを減らす
  • バックグラウンドで実行されているもの(メール、編集など)を監視できます。
  • あなたに自由感を与えます。アトリウムにいるのと、ほうきのクローゼットにいるのに似ています。
  • 等...

2
かつてまさにその問題に直面していました。CEOの1人にメールを書いて、効率が5%向上した場合、純利益に対して約半月でモニターに見合う金額を節約できると明示的に計算しました。この計算はかなり皮肉がかかっていました...しかし...私はあなたがすでに物語の終わりを知っていると思います:)
ラファエル

39

格安のハードウェアに与えられたコンサルタントコンサルタントを超える費用150 $ /時間を

より優れたハードウェアを視野に入れると、少なくとも1日あたりのジョブの効率が30分向上する可能性があります。これにより、30分* 20日間/月= 600分/月= 10時間/月> 1日以上の仕事= 10時間* 150ドル/時間= 1500ドルになります

コンサルタントが1500ドルのコンピューターを持っているとしたら、コンサルタントはより効率的に仕事をしませんか?コンサルタントのイライラを軽減しますか?

問題は、コンサルタント用とPCハードウェア用の2つの予算があることです。


8
コンサルタントとして、私はそこに行って、それをして、Tシャツを手に入れました。(ただし、1時間あたり80ドルしか得られませんでした。)でも、それが時間単位の契約が好きな理由の1つです。給与の高い職とは異なり、コンサルティングクライアントが私の時間を無駄にし、それを補うために余分な仕事をしなければならない場合、それは私のポケットにあるより多くのお金です。
ボブマーフィー

2
違反はありませんが、コンサルタントに1時間あたり150ドルを支払っている場合、彼は自分のコンピューターを持っている方が良いでしょう。
スティーブンエバーズ

8
@SnOrfus:ドメインで許可されているPCを厳密に制御している企業環境では、通常は機能しません。ハードウェアを提供する必要があります。
ハードコード

1
@HardCode-そうだね。私は今ポイントを見ることができます。
スティーブンエバーズ

3
@HardCode最近のプロジェクトでは、私たち(請負業者)を社内の企業ネットワークに追加する代わりに、私たち自身のDSL回線に隔離しました。1か月40ドルで3人の開発者専用のDSL回線が変更されるため、ITスタッフをパニックに陥らせることなく、リモートで簡単に更新をプッシュできます。さらに、コードを実行している実稼働PCが感染してクラッシュした場合、通信と個人のラップトップのセキュリティを担当しているため、自動的に障害となります。win-win-winと言えますか。
エヴァンプレイス

38

数ヶ月の作業で計画の日数を節約

(計画に十分な時間を投資しない)


21
大学院では、研究室で数週間は図書館の時間を1時間節約できるというsayingがありました。
デビッドソーンリー

7
うん。未知の化学物質を特定する学部の研究室の授業を受けていたとき、教授は「図書館で1時間すれば研究室で4人節約できる」と言った。私は彼を真剣に受け止めましたが、週に1時間ワルツを研究室に入れて、明らかにアミンではない化合物のアミンテストを週に12時間費やしていた医療従事者から不快な表情をするのは陽気でした。そして、数年後に同じ研究室を教えたとき、私は学生に同じアドバイスをしました。
ボブマーフィー

3
計画に失敗した場合、失敗する予定です

27

私が疑う最も一般的なのは、マネージャーが単に開発者に仕事を効率的に行うために必要なツールを提供していないことです。

基本的に、ジョエルテストのポイント9 。


2
例えば、すでに仕事が終わって300ドルのライブラリを購入するのではなく、1〜2週間無駄にするプロジェクトに取り組んでいます。または、より優れた代替手段があるかどうかを調べるのではなく、「this or that」の会社が作ったソフトウェアツールを選択して、何年も私たちの人生を地獄にします。
MetalMikester

私は自分でその1つに遭遇しました。PM /クライアントの推論は、クライアントのために物を購入するための予算アイテムがなかったので(連絡先の変更はめちゃくちゃだった)、ホイールを再発明する必要があります(もう一度)。
ケンヘンダーソン

24

「問題に(十分な)遺体を投げる」は、残念ながら一部の場所でまだ使用されています。 ブルックの法則は、この教訓を学ぶために経験を必要とするものもありますが、神話の男月からこれに反論します。一般的に、これは、経営陣が人を追加し、それに代価を払わなくてはならないという誤った声明を信じる可能性があるため、やめる力ではありません。


2
+1。ああ、はい。これは現在、私が働いている主要なプロジェクトで壮大な規模で起こっています。
ボビーテーブル

3
私は彼らのOH-SO-素晴らしいプロジェクト管理認証(それを呼び出して何でも一体)とNOTそのうちの一つは、のことを聞いていたしたすべての人のプロジェクトリーダー、マネージャーなど、たくさんのと連携人月の神話私はそれらを導入する前にそれに。シーシュ!
ボブジャービス

2
これについての素晴らしい引用を一度聞いたことがあります:9人の女性は1か月で赤ちゃんを作ることができません
リチャード

@Richard私は会議でそれを使用しました。私に大きな喜びを与えました!
Tjaart

21

毎日の会議

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...  

9
会議のためだけに会議を開催しています
...-Gan

5
今日の議題:明日の会議の議題には何がありますか?
マークC

9
これらが短い場合は、毎日の会議で問題ありません。スクラム形式の3分間のスタンドアップミーティングは、時間を無駄にしないが、誰もが他のすべての開発を認識し続ける。しかし、多くの無関心な参加者との長い会議は有害です。
9000

3
@マークC -それは冗談のように聞こえるかもしれないが、私は実際に次の日の会合の議題であるものを計画する会議に招待されている...
ギャビン・コーツ

@Gavin Coatesそれは実際の状況です... :)
Zzz

20

社内で開発するのではなく、既製のソフトウェアを購入する。

私は、人事と生物学研究所の両方に焦点を当てた企業規模管理システムの経験があります。

既製のソリューションの費用は£50〜100,000で、ビジネス要件を満たすためにさらなる開発とカスタマイズが必要でした。

社内で開発されたソリューションは、開発に(6か月未満)かかり、他のプロジェクトも並行して作業され、既に採用されている開発者を利用していました。

私は、社内で開発されたLIMS(ラボ情報管理システム)が稼働している公的部門から、既成のソリューションの実装が1年以上かかり、どこでも完了しなかった大規模な国際的な医薬品に行きました。

(既に雇用されている開発者が他のプロジェクトに並行して取り組んでいるので6か月です。約10kです。これには、既製のソリューションに関連するサポートコストは含まれていません)。主なポイントは、社内で開発されたシステムが実際に使用されていたことです!したがって、それに関連する追加の費用便益がありますが、これは計算できません。

私は基本的なウェブサイトなどに同意しますが、なぜ自分で開発するのが面倒です。ただし、大規模で複雑なシステムの場合、および社内スキルを既に持っている場合は、自分で構築します。


26
反対の例もたくさんあるに違いない。
ジョンホプキンス

13
購入または開発することは、デューデリジェンスを行う適切な人々に帰着します。そのような単純な。行動する前に考えてください。(+1)
DevSolo

4
@DevSolo:スポットオン。構築または購入の決定は、感情的な「ここでは発明されていない」または「XXXのソフトウェアが大好き」という態度ではなく、費用便益分析によって裏付けられるべきです。
JBRウィルキンソン

9
ビルドと購入について全面的な声明を発表する場合は、次のようにする必要があります。会社のコアコンピテンシーの一部ではない問題の解決策を購入することです。それは常に正しい答えではありませんが、賢明なデフォルトの位置であり、決まり文句と同じくらい信頼できるものです。しかし、既製のソフトウェアを購入することは偽りの経済であると言うことは、便利な決まり文句でさえありません。「 ')。しかし、悪いオプションが存在するからといって、良いオプションが存在しないわけではありません。
evadeflow

2
問題は購入であり、それでもさらなる開発とカスタマイズが必要だと思います。大規模な持ち込みシステムでの小さなカスタマイズのコストは、多くの場合、必要なことを行う独自の小さなシステムを作成するよりも多くなります。したがって、購入するシステムが期待どおりに機能する場合は購入しますが、購入とカスタマイズは両方の悪い面をもたらす可能性があります!
イアン

15

オープンソースの選択肢がより優れており、無料の場合、高価な既製の製品を購入します。

いくつの会社がgitを使用していますか?いくつもの企業が、くだらない企業のバージョン管理を使用していますか?


1
えーと、これは「最悪の虚偽経済」と考えることができますか?それとももっと詳しく説明する必要があるのでしょうか...?
ガン

3
少なくとも、ソース管理の例に完全に同意するかどうかはわかりません。Gitは、オープンソースの問題を解決するために特別に設計されました。多くの開発者、小さな中央制御、多くのブランチなど。「エンタープライズ」ソフトウェアは、異なる前提の下で機能します。ビジネス、セキュリティ、ワークフローなど
-PeterAllenWebb

1
@Gan:オープンソースを使用することは誤った経済であると考えていますが、それらはすべて逆方向にあります。
長谷

3
私はX11とGNOMEに貢献しており、gitの使用とgitosisサーバーの管理に非常に優れています。それにもかかわらず、この夏、コンサルティング作業をgitから個人用のPerforceサーバーに切り替えました。これは、gitを使用して手動で行う必要のある多くのことを自動的に行うためです。バージョン管理に手を加えずにコードを配信することで報酬が得られるため、「粗雑なエンタープライズバージョン管理」の使用と支払いは、gitを使用するよりもはるかに費用対効果が高くなります。
ボブマーフィー

7
私の経験では、オープンソースと商用製品は本当に「ケースバイケース」ベースです。
MetalMikester

14

表現力をあまり持たない「単純な」言語を使用する

ええ、それはコードを維持するプログラマーを見つけやすくしますが、採用される最新の流行語を学ぶだけではない優秀なプログラマーを見つけるのを難しくします。ええ、それは個々のビットコードを理解しやすくしますが、2x4とほぼ同じくらい硬直させ、理解する必要があるコードの量を増やします。ええ、それは巨大企業に支えられていますが、巨大企業はゆっくりと官僚的に革新すると言いました。


4
@burnt_hand:私は基本的に、言語の選択の観点から経営陣の過度のリスク回避について言及しています。
dsimcha

1
+1:「私たちにはそれらのスキルがあり、Python / Perl / PHPのような新しい派手な言語を学ぶことは多くのリスクを増す」ため、Cを使い続けるだけです。何度も聞いた。それは、チームが愚かすぎて新しい言語を学ぶことができないということですか?
-S.ロット

1
@ S.Lott募集代理店はあなたがいると思います!しかし、それは別の話です
-burnt_hand

2
:JavaとC#に固執し、彼らはのことを思い出す「業界標準」、じゃないので、Pythonやルビーを触れるには余りにも恐れている、すなわち会社paulgraham.com/avg.html
HASEN

1
@hansen:ポール・グラハムのエッセイは、この投稿を書くきっかけになった部分があります。私の他のインスピレーションは、Dプログラミング言語用のライブラリ(標準ライブラリを含む)の開発でした。
dsimcha

13

悪いプロジェクトマネージャー/チームリード。

一人の無能な人には、人々のグループの仕事を台無しにする力があるからです。最終的に、プロジェクトは上位管理者(プロジェクト/チームリード)の決定がなくてもはるかに良くなります。

「すぐにそれを行うだけで、後でリファクタリングします」が決定します。


4
悪いマネージャーがいることに同意しますが、「プロジェクトは、経営陣の意思決定がなくてもはるかにうまくいくでしょう」。一般的に、これらはプロジェクトを後援している人々です。これは、ビジネスを理解し、実際の顧客が誰であるかを忘れるよりも、テクノロジーを理解することが重要だと思う、出会った開発者のように思えます。
ジョンホプキンス

2
@Jon Hopkins上級管理職の場合、顧客を紹介しません。重要なのは、「悪いプロジェクトマネージャー」とは、間違いを犯してから間違いを犯し、人々のグループに反対する人たちです。誰が「すぐにそれを行うだけで、後でリファクタリングする」と決めると思いますか。最高のレートで答えを読んでください!
アミールレザエイ

ああ、より明確。-1を削除します。
ジョンホプキンス

私は、プロジェクトマネージャーが品質よりも時間とコストを重視しているという不穏な傾向に気付きました。私は私だけではないと確信しています。PMは、コスト/品質/時間の三角形ダイアグラムを使用するのが好きですが、品質は常に最初に起動します。それは非常に悲しいことであり、ソフトウェアと同じくらい複雑なものにプロジェクト管理(PMI)のメトリックを制度化して強制することは、事態を悪化させているようです。
バーナードDy

1
@Bernard-時間とコストは測定可能です。品質?そんなにない。悲しいけどIMO真...
ボブ・ジャービス

12

ユーザー要件がありません

ソフトウェア製品を設計する際の重要で難しいステップは、顧客が実際に何をしたいかを決定することです。

信じられないかもしれませんが、この部分が欠落しているか、時代遅れであることがあります。コストになるのは、エンドユーザーが決して要求しなかった機能を作成することです。


これが一番上にあると思います!
ルーペシュシェノイ

8

生産性は創造性よりも価値があります

一般的に、創造性は測定するのが難しく、ソフトウェア開発に関しては、測定することを気にせず、観察することすらほとんど不可能です。一方、生産性は測定することができ(しばしば不十分)、観察することができます。

結果として、(より多くのコード行を書く|質問に応じてテクノバブルをより速く書く|より生産的に見える)開発者は、同じ問題を解決するためにコードの行数を減らす|よりも高く評価される傾向があります。コードを書くのに時間がかかりますが、より信頼性の高い製品を作成する|主題をわかりやすく、わかりやすく、英語で|創造的に解決するのに十分なほど十分に理解してください。


6

以下のすべては、使用時に不適切であるか、不適切に使用されていないことがあります

  • 外部ソフトウェアと社内ソフトウェア

  • ISO 9001準拠(エコノミー-製品の品質が低下した場合のMSS損失リスクの軽減)

  • 開発/ QAアウトソーシング

  • 開発/ビルド/リリース/サポート手順


ISO 9001は(誤った)「経済」とはどのようなものですか?
アンドリューグリム

@Andrew Grimm-コンプライアンスにより、低品質(たとえば、MSS損失)から生じるリスクを軽減する特定の品質レベルが保証されるため、潜在的な経済性が明確になります。小規模部門では、オーバーヘッドの損失が潜在的なリスクからの損失よりも大きいため、これは不適切である可能性があります
-bobah

1
@アンドリュー-私の経験では、それはあなたがそれを望むものに依存します。品質を向上させたい場合は、高価になる傾向があり、ソフトウェアに適さない可能性があるため、おそらく誤った経済です。マーケティングの目的として、またはあなたの業界で期待されているだけの理由でそれを望むなら、それは潜在的に良い考えです。
ジョンホプキンス

5
@Andrew Grimm-ISO 9001が保証する「唯一の」ことは、一貫した再現可能な品質です。「高」品質を保証するものではありません。ただし、ISO 9001の資格が、会社が参入したい市場で必要なものである場合、それは必須です。
バティーン

1
@Vatine:ISO 9001が保証しているのは、一貫性のある繰り返し可能なプロセスです。一貫したプロセスが一貫した品質を生み出す一部の分野では、それは重要です。それは高品質を保証するものではありませんが、顧客があなたがよくやったことを見て、あなたがISO 9001認証を受けていることを知っていれば、彼らは同様の品質に自信を持っています。
デビッドソーンリー

4

請求できない配送マネージャーが多すぎます。

数年前、私たちの会社ではいくつかの大きな予算プロジェクトが進行中で、採用はピークに達していました。当時、私たちの会社はあまりにも多くのデリバリマネージャーを雇いました(その多くはIT担当者ではありませんでした!)。マネージャーとプログラマーの比率は文字通り1:2でした。その後、これらのプロジェクトの完了後、私たちはこれらのマネージャーの多く(何人かは本物の怠け者)がベンチに座って何もしていなかった状況にありました。会社が誰も解雇する必要がないように、誰も昇給をほとんど/まったく行わない評価サイクルがありました(私たちの勤勉なプログラマでさえ、ため息です)!幸いなことに、同社はこの状況を認識し、今年の第1四半期に適切な評価を行いました。


3

プロファイリング前の最適化(時期尚早の最適化)。

私は誰かが、より速いという理由でメンテナンスと読みやすさを不必要に複雑にする賢い解決策に手を伸ばすのを見てきました。当然、コードは(マイクロベンチマークでもなく)ベンチマークされていないので、コード全体で全体のパフォーマンスに影響を与えない可能性が高いコードのセクションですぐに「説得力のある引数に基づいて高速」になります。多くのアプリケーション。

このように、それは非常に偽りの経済であり、ベテランのプロさえも時々巻き込む一種の偽りの経済です。


3

インターネットアクセスが制限されているか、まったくない

明らかに、従業員はインターネットを使用してFacebookゲームをプレイするので、Stackoverflowの技術的な質問に対する答えをあまり調べません。

もちろん、実際にはインターネットは生産性を大幅に向上させますが、真に危険なサイトには何らかの種類のサイトフィルターを使用するのが適切かもしれませんが、視覚スタジオのreadmeファイルをブロックしたり、Telford地方自治体のページをブロックしたりすると、何らかの問題が発生します「セックスツーリズム」


2

開発者が企業標準である15インチモニターと低スペックPCを使用するようにします。

リーズナブルなサイズのモニターは安価で、インストールが簡単で、プログラマーの生産性を高めるだけでなく、プログラマーに自分のことを気にかけていると思わせることができます。


2

階層的に組織化された経営管理学士(など)が多すぎて、現代の経営について考えていることを適用しようとしています。「KPI」、「SLA」、およびそうでない人を悩ませ、「レポート」(もちろん、それらを生成するためのインフラストラクチャを気にかけます)、プログラマーが豪華なEXCELシート、Q4レポート、その他のものを埋めて、1つの素晴らしい新しい管理ツールからコピーして別の管理ツールに貼り付ける(それがルールであるようです)これらのツールは互いに統合されたり統合されたりすることはありません)、レポートや数値が提示される会議に出席します(そして、誰もがこのKPIを満たせなかったことに罪悪感を覚えます)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.