我们都曾在某个时候这么说过，而且通常只是在工作场所经常发牢骚。但是软件开发人员正处于一个困难的境地，因为当你的老板对软件开发一无所知时，这会让你的工作变得更加困难。

老板们可能会认为他们知道自己在做什么——毕竟，设定一个截止日期并期望人们能完成它有多难呢？但是软件开发有一种特殊的工作方式，这对非技术经理来说是没有意义的。

例如：

1. 让更多的人参与一个项目适得其反缺乏经验或没有软件背景的经理通常认为，如果他们在项目中引入更多的“暖体”，团队就会工作得更快。这是不不对的，总会引起开发团队的抱怨。添加人员并没有加快速度，反而会减慢速度。一个资深的团队成员将不得不把他们正在做的事情放在一边，以便让新人跟上团队的进度。如果这个人是新员工或新手，问题会变得更糟，因为这个新手所做的任何事情都必须经过其中一位老手的再三检查——同样，这也是花在实际任务之外的宝贵时间。

2. 你不能只是“添加一些东西”涉众能说出的最危险的话是，“他们能直接添加某种特性吗吗？”涉众和用户都不是程序员，他们甚至不知道自己看似微不足道的请求是否可行，更不知道以一种不会破坏项目中其他一切的方式引入这些请求有多难。问题是管理者容易受到涉众压力的影响，容易盲目地接受请求，将团队投入到比最初引用的经理花费更多时间的事情中，这增加了团队的压力，并可能导致更多的错误。最后，没有人是快乐的。

3.QA不可能捕捉到每一个bug经理们(尤其是非技术人员)似乎认为任何通过QA的代码都应该是干净的，零缺陷！这就是我们的目标。QA每天花费数小时梳理代码，测试各种功能和用例，以排除bug。但是很难测试复杂的软件程序，因为要处理的变量太多了。即使是附加文件的简单行为也可能成为QA的挑战。您测试了多少种文件类型？它们有多大？文件名有多长？这些因素中的每一个都可能触发一个bug，并且随着软件的一部分与其他部分交互(例如，在上传附件后发送电子邮件)，这种可能性会成倍增加。QA很难测试所有的变量。关于bug的另一件事是它们的行为不符合逻辑。有些bug只能在最特殊和最古怪的情况下触发(例如，如果您按了52次“Like”按钮，程序就会崩溃)。QA不能预测所有可能的行为和条件。

4. 使用其他人的代码总是一场噩梦编写代码与编写汽车引擎是两码事。代码在不同的企业、部门、团队，甚至程序员之间差异很大。所以使用别人的代码就像在雷区行走。您不知道代码是如何构建的，不知道一个部分如何与另一个部分交互，也不知道更改是否会突然出现在您的面前，从而使程序的其余部分也随之消失。

5. 努力和效率不是一回事许多经理似乎认为，如果你在某件事上花了很多时间，那么这个项目一定在向前推进。虽然大多数时候都是这样，但也有完全相反的情况。如果您需要一个例子，请回到我们前面关于使用其他人的代码的观点。你的大部分时间将花在阅读它，并试图找出它的作用。直到很久以后，你才有足够的信心在不破坏任何东西的情况下改变它。

6. 技术债务是真实存在的当大多数老板面临做正确的事情和快速的事情之间的选择时，他们会选择后者。产品仍然有效，而且老板看起来很擅长运用“管理技巧”将产品推出市场。除了这种快速和肮脏的解决方案很可能会导致更大的问题。草率的代码几乎总是会导致破坏未来工作的复杂性。