blocks|key|4691389|text|技术债务|type|header-two|depth|inlineStyleRanges|entityRanges|data|4691390|“快点做，我们稍后再做”。首先，因为我还没有看到有人参与到这种行为中去，后来才真正重构。第二，因为用快速的方式做事，而不是用好的方法来增加未来的特性或解决未来的错误，最终你最终会浪费时间。|unstyled|4691391|不幸的是，许多人仍然认为让开发人员快速完成某些事情可以节省开发人员的周期。我想这是可能的，但我还没有在实践中看到它。|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|I|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|J|8|@]|9|@]|A|$]]]|G|$]]

<h2>Technical Debt</h2>

ie "Just do it quickly, we'll refactor later". Firstly because I have yet to see someone engaging in this behaviour actually refactor later. Secondly because doing things the quick way, instead of the good way makes it harder to add future features or resolve future bugs so you end up losing time in the long run.

Sadly, many still think it saves developer cycles to have them do something fast. I guess it's possible, but I have yet to see it in practice.

blocks|key|951304|text|雇佣两个便宜的开发人员，而不是一个真的很棒。(相同的价格)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Hiring 2 cheap developers instead of 1 really great. (for the same price)

blocks|key|951435|text|我的例子将与尼姆·辛普斯基的例子完全相反，即：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|951436|试图开发内部的东西，可以买到现成的.|header-two|951437|通常情况下，这是因为没有真正地检查市场的位置，看是否已经存在一些能解决问题的东西。更复杂的是，开发人员喜欢在进行任何研究之前“投入”编码，以及项目经理没有考虑到这一时间=金钱。|951438|我在我的领域中看到的最常见的例子之一，web开发，是那些试图开发和内部CMS系统的公司。这些总是从小的，但很快就会变得臃肿和失控的功能螺栓上，而所有的时间，有大量的免费产品和框架-在那里会更适合。|entityMap|0|LINK|mutability|MUTABLE|url|https://softwareengineering.stackexchange.com/questions/19573/what-are-the-worst-false-economies-in-software-development/19574#19574^0|6|A|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|F|7|V|8|@]|9|@]|C|$]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

My example would be the complete opposite of <a href="https://softwareengineering.stackexchange.com/questions/19573/what-are-the-worst-false-economies-in-software-development/19574#19574">NimChimpsky's example</a>, namely:

Trying to develop in-house something that can be bought off-the-shelf.

Normally this comes about due to a failure to actually check the market-place to see if something already exists that will solve the problem. This can be compounded by developers who like to "dive in" coding before doing any research and by project managers who fail to factor in that time = money.

One of the most common examples I've seen in my field, web development, are companies trying to develop and in-house CMS system. These invariably start off small, but soon get bloated and out-of-control as features are bolted on, whilst all the time there are plenty of free products and frameworks out-there that would be much better suited.

blocks|key|951557|text|没有用于项目管理的专用资源|type|header-two|depth|inlineStyleRanges|entityRanges|data|951558|我已经经历过好几次，有几个程序员签了合同，已经有一份要求很高的日常工作的人应该管理这个项目，但是事实上，其他任务太忙了，所以这个项目从来没有真正获得动力。程序员们制作了“原型”之类的东西，但是没有一个线索，很多东西都是绕圈运行的，看起来很忙。|unstyled|951559|新程序员的|951560|坏设备|951561|我曾经经历过一家公司，公司的政策是“新程序员必须在一台非常老的电脑上工作，屏幕很小，直到他们证明自己是有价值的”。不足为奇的是，这样的政策导致了消极的选择，赶走了那些总是可以选择在更理智的环境中工作的好人。|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|M|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|N|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$]]]|K|$]]

No dedicated resources for project management

I've experienced several times when a few programmers were contracted, and someone who already has a demanding day-job should have managed the project, but in fact was too busy with other tasks so the project never really gained momentum. The programmers made "prototypes" and stuff, but without a lead, much of it was running in circles to look busy.

Bad equipment for new programmers

I've once experienced a company where the policy was "new programmers have to work on an really old PC with a small screen until they prove they are worthy". No surprise that such a policy caused a negative selection that drove off good people who always have the choice to work in a more sane environment.

blocks|key|4691608|text|我们可以通过让程序员加倍做测试员/技术作者|type|header-two|depth|inlineStyleRanges|entityRanges|data|4691609|来省钱|unstyled|4691610|如果你为测试员/技术撰稿人的工作支付程序员的薪水，那么你就是在浪费金钱，而且可能比那些致力于这项工作的人得到更低质量的工作。此外，当程序员面临紧迫的截止日期时，测试和文档很可能会被丢弃或半途而废。|4691611|顺便说一句:开发人员总是面临一个紧迫的截止日期。|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|K|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|L|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|M|8|@]|9|@]|A|$]]]|I|$]]

We can save money by having the programmers double as testers/technical writers

If you are paying programmer salaries for tester/technical writer work, then you are wasting money and likely getting lower quality work than someone who has dedicated their career to that task. Also, when a programmer is up against a tight deadline testing and documentation are very likely to get dropped or done half-ass to meet it. 

BTW: Developers are ALWAYS up against a tight deadline.

blocks|key|4691433|text|在许多情况下，离岸外包成本更高。在我的公司，很难找到新的员工职位，我们被强烈要求外包。这也是很难找到现场承包商；有3:1的离岸和岸上的比例，他们应该保持。因此，许多团队只雇佣了十几个离岸公司，几乎没有使用它们，这样他们就可以得到4个现场承包商。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

In many cases offshoring costs more money. In my company it's very hard to get new employee slots, we are pushed heavily to outsource. Its also hard to get on-site contractors; there is ratio of 3:1 offshore to onshore they are supposed to maintain. Consequently, many teams just hire a dozen offshore and barely use them at all, just so they can get 4 onsite contractors.

blocks|key|4691964|text|长反馈回路！|type|header-two|depth|inlineStyleRanges|entityRanges|data|4691965|这发生在每个人身上:你建造了一些你认为很棒的东西，结果发现你错了。这不是问题所在。问题是你花了多长时间才发现你应该停下来。|unstyled|4691966|在高级别上，您可以看到长发布周期的问题。如果你在没有反馈的情况下建了一年，你就赌了整整一年。你释放的次数越多，你的赌局就越小，你赌得越好。|4691967|但它也发生在最低水平。作为一名开发人员，我非常喜欢频繁的代码评审(或者更好的是双编程)，因为它限制了我在别人说“嘿，还有更简单的方法！”之前继续做一些愚蠢的事情的时间！出于同样的原因，我喜欢我的单元测试快速、频繁地运行，这样我就可以在bug生长之前捕获并杀死它们。|4691968|一旦你开始注意到短反馈循环的重要性，你会发现它无处不在。例如，官方发展援助回路的军事概念。|offset|length|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/OODA_loop^0|0|0|0|0|V|8|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|U|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|V|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|X|8|@]|9|@$K|Y|L|Z|1|10]]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]]]

Long feedback loops!

It happens to everybody: you build something that you think is awesome, and it turns out you were wrong. That isn't the problem. The problem is how long you spend building before finding out that you should stop.

At the high level, you see this problem with long release cycles. If you build for a year without feedback, you're gambling the whole year. The more often you release, the smaller your gambles, and the better you get at gambling.

But it also happens at the lowest levels. As a developer, I really like frequent code reviews (or, better, pair programming) because it limits the amount of time I can continue doing something dumb before somebody says, "Hey, there's a simpler way!" For the same reason, I like my unit tests to run quickly and frequently, so I can catch and kill bugs before they grow.

Once you start noticing the importance of short feedback loops, you'll see it everywhere. E.g., the military notion of the <a href="http://en.wikipedia.org/wiki/OODA_loop">OODA loop</a>.

blocks|key|951513|text|这不是我自己的轶事，但我曾经听说过一家商店不再向开发商提供免费咖啡，而是告诉他们，只要他们想要喝咖啡，他们就可以自由地步行到最近的咖啡店(大约每次10分钟的路程)并购买一些咖啡。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|951514|差不多就是假经济的定义。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

Not my own anecdote, but I did once hear of a shop which stopped providing free coffee to its developers, telling them instead that any time they wanted to get coffee, they were free to walk to the nearest coffee shop (something like a ten minute trip each way) and purchase some.

Pretty much the definition of false economy.

blocks|key|4692001|text|提供单屏幕工作站，因为第二个监视器太贵了。即使它每年只为你节省一个小时的工作时间，第二个屏幕仍然是一个很好的投资。我确信我的工作为我节省了很多，很多小时的时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4692002|多监视器设置可以提高几乎任何任务的效率，而不仅仅是开发任务。三个显示器甚至比两个显示器要好，但是每增加一个屏幕，效果就会变得不那么明显。|4692003|多监视器设置：|4692004|降低窗口切换开销|unordered-list-item|4692005|允许您监视在后台运行的东西(邮件、编译等)。|4692006|给你一种自由的感觉。就像在中庭和扫帚壁橱里一样。|4692007|等等。|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|H|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|V|8|@]|9|@]|A|$]]]|O|$]]

Providing single-screen workstations because a second monitor is too expensive. Even if it only saves you an hour of work each year, an second screen is still a good investment. I know for sure that mine has saved me many, many hours of work.

A Multi-monitor setup can make almost any task more efficient, not only development tasks. Three monitors is even better than two, but the effect becomes less pronounced with every extra screen.

Multi-monitor setups:

<ul>
<li>decrease window switching overhead </li>
<li>allow you to keep an eye on stuff running in the background (mail, compilation, etc.).</li>
<li>give you a feeling of freedom. It's like being in an atrium vs. being in a broom closet.</li>
<li>etc...</li>
</ul>

blocks|key|4691729|text|几个月的工作节省了|type|header-two|depth|inlineStyleRanges|entityRanges|data|4691730|计划的天数|unstyled|4691731|(在规划上没有投入足够的时间)|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|I|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|J|8|@]|9|@]|A|$]]]|G|$]]

Months of work save days of planning

(Not investing enough time into planning)

blocks|key|4691339|text|我怀疑最普遍的情况是，管理人员根本没有为开发人员提供有效完成工作所需的工具。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4691340|基本上，乔尔试验上的第9点。|offset|length|entityMap|0|LINK|mutability|MUTABLE|url|http://www.joelonsoftware.com/articles/fog0000000043.html^0|0|4|4|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]]|F|$G|$5|H|I|J|A|$K|L]]]]

Most prevalent I suspect is managers simply not providing developers with the tools they need to do their job efficiently. 

Basically, point 9 on the <a href="http://www.joelonsoftware.com/articles/fog0000000043.html">Joel Test</a>.

blocks|key|951750|text|不幸的是，“把(足够多的)身体扔到这个问题上”仍可能在某些地方使用。布鲁克定律确实从神话中的男人月那里反其道而行之，尽管有些人需要经验才能学到这一课。一般来说，这不是我力所能及的事情，因为管理层可能会相信关于增加员工而不必为此付出代价的错误说法。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Death_march_%2528software_development%2529|1|http://en.wikipedia.org/wiki/Brooks%2527s_law|2|http://en.wikipedia.org/wiki/The_Mythical_Man-Month^0|5|I|0|Y|5|1|16|7|2^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@$A|P|B|Q|1|R]|$A|S|B|T|1|U]|$A|V|B|W|1|X]]|C|$]]]|D|$E|$5|F|G|H|C|$I|J]]|K|$5|F|G|H|C|$I|L]]|M|$5|F|G|H|C|$I|N]]]]

<a href="http://en.wikipedia.org/wiki/Death_march_%28software_development%29">"Throw (enough) bodies at the problem"</a> may still be used in some places, unfortunately. <a href="http://en.wikipedia.org/wiki/Brooks%27s_law">Brook's Law</a> does counter this from <a href="http://en.wikipedia.org/wiki/The_Mythical_Man-Month">The Mythical Man-Month</a>, though some require experience to learn this lesson. Generally this isn't something within my power to stop as management may believe the false statement about adding people and not having to pay a price for it.

blocks|key|951890|text|每日会议：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|951891|(meeting+duration+in+hours)+x+(Y+team+members)+x+(average+salary+per+hour)+=+...++|code-block|syntax|javascript|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|I|8|@]|9|@]|A|$E|F]]]|G|$]]

Everyday meetings: 

<pre><code>(meeting duration in hours) x (Y team members) x (average salary per hour) = ... 
</code></pre>

blocks|key|951180|text|买下现成的软件而不是内部开发它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|951181|我有企业规模管理系统的经验，专注于人力资源和生物实验室。|951182|现成的解决方案花费了GB50-100k，需要进一步开发和定制，以满足业务需求。|951183|内部开发的解决方案花费了(<6)个月的时间来开发，其他项目同时进行，并使用了已经雇用的开发人员。|951184|我从一个内部开发的LIMS+(实验室信息管理系统)开始运行的公共部门，到一家大型国际制药公司，在那里，一种现成的解决方案的实施花费了一年多的时间，但还远远没有完成。|951185|(已经雇用的开发人员6个月同时从事其他项目。所以，10K。这不包括与现成解决方案相关的支持费用)。主要的一点是，内部开发的系统实际上正在被使用！因此，您将得到与此相关的附加成本效益，我无法计算。|951186|我同意基本网站等等，为什么要自己开发自己的网站呢？但是对于任何大型的复杂系统，如果你已经具备了内部技能，我会自己构建它。|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|S|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|T|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|U|8|@]|9|@]|A|$]]]|N|$]]

Buying off the shelf software instead of developing it internally.

I have experience of entreprise scale management systems, focussed on both HR and Biological Laboratories. 

An off the shelf solution cost £50-100k and needed further development and customisation to meet the business requirements.

The internally developed solution took (&lt;6) months to develop, with other projects being worked on in parallel, and utilized an already employed developer.

I went from the public sector where we had an internally developed LIMS (lab information management system) up and running, to a large international pharmaceutical where the implemention of an off the shelf solution had taken over a year and was nowhere complete.

(6 months of an already hired developer working on other projects in parallel. So ~10k. And that doesn't include the support costs associated with the off shelf solution). The major point is that the internally developed system was actually being used! So you then have the added cost benefit associated with that, which I cannot calculate. 

I'd agree for basic websites etc, why bother developing your own. But for any large complex systems and if you already have in house skills, I'd build it myself.

blocks|key|951871|text|在开源产品更好、更免费的情况下，购买昂贵的非搁置产品。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|951872|有多少公司使用git？有多少公司使用一些拙劣的企业版控制？|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

Buying expensive off-the-shelve products when the open source alternatives are better and free.

How many companies use git? How many companies use some crappy enterprisey version control?

blocks|key|951678|text|使用“简单”语言，没有很强的表现力|type|header-two|depth|inlineStyleRanges|entityRanges|data|951679|是的，它使找到程序员来维护代码变得更容易，但也使找到优秀的程序员变得更加困难，因为他们不仅仅是学习了最新的流行词汇，才能让他们获得聘用。是的，它使单个位代码更容易理解，但也使其与2x4一样僵化，并增加了需要理解的代码量。是的，它得到了一家大公司的支持，但它说，大公司的创新速度缓慢，而且官僚主义。|unstyled|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|G|8|@]|9|@]|A|$]]]|E|$]]

<h3>Using &quot;simple&quot; languages without much expressiveness</h3>
Yeah, it makes it easier to find programmers to maintain the code, but it makes it harder to find good programmers who don't just learn the latest buzzword that will get them hired. Yeah, it makes individual bits code easier to understand, but it also makes it about as rigid as a 2x4 and increases the volume of code that needs to be understood. Yeah, it's backed by a huge corporation, but said huge corporation innovates slowly and bureaucratically.

blocks|key|4691471|text|糟糕的项目经理/团队领导。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4691472|因为一个无能的人有权毁掉一群人的工作。最后，如果没有高层管理人员(项目/团队领导)的决策，项目会做得更好。|4691473|“快点去做，我们以后再重构”是吗？|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|G|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|H|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|I|8|@]|9|@]|A|$]]]|F|$]]

Bad project managers/team lead.

Since one incompetent person’s have the power to ruin the work of a group of people. In the end, the project would do much better without upper management(project/team lead) decisions.

Dose the "Just do it quickly, we'll refactor later" decides.

blocks|key|951911|text|缺少用户需求|type|header-two|depth|inlineStyleRanges|entityRanges|data|951912|设计软件产品的一个重要而困难的步骤是确定客户真正希望它做什么。|blockquote|951913|信不信由你，有时这部分已经丢失或过时了。它的成本是，一个创造的功能，最终用户从来没有要求。|unstyled|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|K|8|@]|9|@]|A|$]]]|H|$]]

Missing user requirements

<blockquote>
 An important and difficult step of
 designing a software product is
 determining what the customer actually
 wants it to do.
</blockquote>

Believe it or not sometimes this part is missing or is outdated.
What it comes to cost is that one creates functionalities that the end user never asked for.

blocks|key|951933|text|生产力比创造力更有价值|type|header-two|depth|inlineStyleRanges|entityRanges|data|951934|创造力在一般情况下是很难衡量的，而且当涉及到软件开发时，往往是不可能观察到的，更别提衡量了。另一方面，生产力是可以衡量的(通常是很差的)，而且是可以观察的。|unstyled|951935|因此，开发人员能够(编写更多代码行，更快地编写代码，更快地背诵技术，以回答问题)比那些(使用较少的代码来解决相同的问题需要更长的时间来编写代码，但生成一个更可靠的产品-能够很好地理解主题，以简单易懂的英语创造性地解决问题-)更有价值。|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|I|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|J|8|@]|9|@]|A|$]]]|G|$]]

Productivity is worth more than creativity

Creativity is difficult to measure in general, and most often impossible to even observe, never mind measure, when it comes to software development. Productivity, on the other hand, can be measure (often poorly), and can be observed. 

As a result, developers which can (write more lines of code|write code faster|recite technobabble faster in response to questions|are more visibly productive) tend to be valued more than those which (use fewer lines of code to solve same problem|take longer to write code, but produce a more reliable product|understand the subject matter well enough to answer questions in plain, easy to understand, English|creatively solve problems).

blocks|key|951228|text|如果使用不当或不适当地使用，下面的所有内容都可能是不好的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|951229|外部软件与内部软件|unordered-list-item|951230|符合ISO+9001标准(经济)-如果产品质量下降，降低MSS损失风险|951231|发展/质量保证外包|951232|开发/构建/发布/支持程序|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|M|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|N|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$]]]|K|$]]

All below can be bad when used or not used inappropriately

<ul>
<li>external vs inhouse software</li>
<li>ISO 9001 compliance (economy - a mitigation of a MSS loss risk if product quality drops)</li>
<li>development/QA outsourcing </li>
<li>development/build/release/support procedures</li>
</ul>

blocks|key|951951|text|有太多的不可计费的交付管理器.|type|header-two|depth|inlineStyleRanges|entityRanges|data|951952|几年前，在我们公司，我们有几个大的预算项目正在进行，招聘工作正处于高峰。当时我们公司雇佣了太多的送货经理(他们中的很多都是非IT人员！)而且很少有程序员/测试人员。经理与程序员的比例实际上是1:2。后来，在这些项目完成后，我们遇到了这样的情况:许多经理(有些是真正的懒鬼)坐在板凳上无所事事。我们有一个评估周期，每个人都得到很少的/没有加薪(即使是我们努力工作的程序员，叹息)，这样公司就不必解雇任何人！幸运的是，公司意识到了这种情况，并在今年第一季度进行了调整！|unstyled|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|G|8|@]|9|@]|A|$]]]|E|$]]

Having too many non-billable delivery managers.

Couple of years ago, in our company we had several big budget projects going on and recruitment was at peak. At that time our company hired too many delivery managers (Many of them were non IT!) and very few coders/testers. Manager to Programmer ratio was literally 1:2. Later, after completion of those projects, we had a situation where we had many of these managers (some of them were real slackers) sitting on bench doing nothing. We had one appraisal cycle where everyone got little/no raise (Even us hardworking programmers, sigh) so that company don't have to lay anyone off! Fortunately, company realized this situation and did the RIGHTSIZING in the first quarter this year!

blocks|key|4692040|text|分析前的|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4692041|优化(也称为过早优化).|header-two|4692042|很多时候，我看到有人提出了一个聪明的解决方案，这不必要地复杂化了维护和可读性，理由是它更快。当然，代码还没有被标出台面(即使是微基准)，所以它很快就会变得“基于更有说服力的论点”，而不是对整个应用程序的整体性能有多大的影响。|4692043|因此，这是一种非常虚假的经济，这种虚假的经济有时也会牵扯到经验丰富的专业人士。|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|K|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|L|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]]|I|$]]

Optimization before profiling (aka premature optimization).

Too many times I've seen someone reach for a clever solution which needlessly complicates maintenance and readability on the grounds that it's faster. Naturally, the code hasn't been bench marked (not even with micro-benchmarks), so it quickly becomes "faster based on the more persuasive argument" over a section of code which most likely didn't impact the overall performance of the entire application by much.

As such, it is a very false economy, and the kind of false economy that occasionally entangles even the seasoned pros.

blocks|key|4692080|text|有限公司或无互联网接入|type|header-two|depth|inlineStyleRanges|entityRanges|data|4692081|因为很明显，你的员工会使用互联网玩facebook游戏，而不是对Stackoverflow上的技术问题进行过多的研究。|unstyled|4692082|当然，在现实中，互联网是一个巨大的生产力提升，虽然使用某种站点过滤器可能是适当的，但如果它以“性旅游”为由封锁visual+studio自述文件或屏蔽telford地方政府页面，则会出现一些错误。|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|I|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|J|8|@]|9|@]|A|$]]]|G|$]]

Limited or no internet access

Because obviously your employees will use use the internet to play facebook games not too research answers to technical questions on Stackoverflow. 

In reality of course the internet is a huge productivity boost, and while it may be appropriate to use some sort of site filter for genuinely dodgy sites there is something wrong if it is blocking the visual studio readme file or blocking telford local goverment pages for reason "sex tourism"

blocks|key|951968|text|使您的开发人员使用15英寸的监视器和低规格的PC，因为它是公司的标准.|type|header-two|depth|inlineStyleRanges|entityRanges|data|951969|合理大小的显示器价格低廉，安装速度快，使程序员更有效率，同时也让程序员认为你关心他们。|unstyled|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|G|8|@]|9|@]|A|$]]]|E|$]]

Making your developers use a 15 inch monitor and low spec PC as it is the corporate standard.

Reasonable sized monitors are cheap, quick to install and make the programmers more productive as well as making your programmers think you care about them.

blocks|key|951981|text|太多的企业管理学士(或类似的)试图应用他们认为现代管理的内容:用"KPI"s、"SLA"s和什么不需要“报告”(当然，不关心生成报告的基础设施)来困扰人们，这样程序员就会浪费时间填写漂亮的EXCEL表格、Q4报告，以及那些不是从一个伟大的新管理工具中复制并粘贴到另一个管理工具中的东西(这似乎是这样的规则:这些工具永远不会相互融合或集成)，并出席会议，其中的报告和数字提出(每个人都感到内疚，因为没有充分说明这个或那个KPI)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Too many Bachelors of Business Administration (or the like), hierarchically organized, that try to apply what they think modern management is about: Bothering people with "KPI"s, "SLA"s and what not, requiring "reports" (without, of course, caring about the infrastructure to generate them), so that programmers waste their days filling in fancy EXCEL sheets, Q4 reports and what not and copy from one great new management tool and paste into another one (it seems to be the rule that these tools are never inegrated nor integratable with each other), and attend meetings where the reports and figures are presented (and everybody is made feeling guilty about having failed to fullfil this or that KPI).

What are the worst false economies (that is ways of saving money that ultimately cost more than they save) prevalent in the software industry and how do you combat them?

What are the worst false economies in software development?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在软件行业中，最糟糕的虚假经济是什么(这是节约资金的方式，最终成本高于储蓄)，你如何应对它们？

问软件开发中最糟糕的虚假经济是什么？
EN

回答 25

Software Engineering用户

技术债务

Software Engineering用户

Software Engineering用户

试图开发内部的东西，可以买到现成的.

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问软件开发中最糟糕的虚假经济是什么？EN

回答 25

Software Engineering用户

技术债务

Software Engineering用户

Software Engineering用户

试图开发内部的东西，可以买到现成的.

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问软件开发中最糟糕的虚假经济是什么？
EN