如何衡量运行Visual Studio的慢速PC的生产力损失？

Question

我们在开发团队中使用的许多PC都已过时，并且运行Visual Studio 2008的速度非常慢。它们应该被更新的机器取代。但管理层/公司普遍不愿购买新机器。

我们如何提出数字和基准来证明这些慢速PC导致生产力下降？

显然，当我们构建解决方案和/或打开各种文件时，我们无法让他们与我们坐下来。

是否有客观的方法来提出非技术人员可以理解的某种可靠数字？

在运行Visual Studio的许多不同PC上，有一种方法可以在整个组织中测量这一点。我正在寻找一个比使用物理秒表更好的答案。 ：）

Answer 1

修改您的解决方案，以便预构建和后构建事件将当前时间写入集中式数据库。包括机器名称和项目名称。

然后，您可以将此信息显示为显示构建与机器的时间的图表。

这应该显示构建时间和机器年龄之间的相关性，希望显示较旧的机器较慢。您甚至可以将时间转换为$（或£或€）值，以显示这些旧机器的成本。总结这一点将为新机器的任何投资提供回报价值。

通过修改解决方案，您可以通过简单地让每个人从源代码管理中“获取最新”来将此日志记录部署到所有开发计算机上。

Answer 2

这并不能真正回答您的问题，但可能有助于实现所需的结果。告诉你的老板The Programmer's Bill of Rights要认真对待。

Answer 3

我会尝试向他们解释程序员比机器花费更多 。如果你每天花30分钟等待，那么算一算，弄清楚由于机器滞后而浪费了多少工资。向他们展示这些数字，并将其与新计算机的价格进行比较，并解释他们如何通过升级来节省资金。

如果他们选择继续花大价钱提供你的智慧只让你坐在那里看一个旋转的光标，只是笑，因为笑话就在他们身上。

Answer 4

许多PHB都从代码行（IMO非常错误）中了解生产力。

你能记录慢速机器上每天产生的代码量而不是慢机器吗？

Answer 5

慢速机器是开发的祸根，恕我直言，特别是因为任何延迟都会让开发人员失去注意力，并且可能导致更加昂贵的转向Web浏览器。当您悬停某个方法时，可能会出现其他奇怪的效果，例如Javadoc弹出窗口或C＃等效的延迟略有增加），并且有人可能会查阅该文档。

如果贵公司合法（至少自用），请使用像Camtasia这样的屏幕捕获工具记录大约半小时的工作。然后使用快速编辑器来查看机器挂起的时间（如果您有光标更改，进度条等，则很容易）并计算实例的时间和数量。我已经完成了几个小时的磁带 - 它不需要那么长时间。使用这些数字来证明这种情况，尽管你还需要争辩说它会导致像上下文切换这样的间接成本。

另外，根据我的经验，硬盘驱动器通常是导致速度减慢的主要原因，而不是CPU或RAM，不幸的是，大多数组织都在使用快速硬盘驱动器或SSD，并且对更换它们有非常严格的规定。

Answer 6

不要忘记考虑花费时间花费多少PC费用的时间成本（换句话说，这篇文章）！