有价值的数据
本书后续章节将讨论一些特定的程序员度量。某些度量相当简单，基于产品bug这类原子数据；而有些度量相对更复杂一些，它们需要利用公式以及多个数据元素的组合。
无论如何，在深入探究特定的度量之前，我们都应考虑各种可用于程序员度量的数据类型，并思考这些数据是否有用处。我们需要广泛而深入地思考那些令人关注的、新的数据元素，因为它们能够带来更有意义的度量。同样，程序员和软件团队的工作需要关联到团队和组织的目标。我们也同样需要认真地思考如何确定这些数据。
下面的列表是我发现的一些有用的数据示例，将在后续章节深入讨论。此处只是说明性质的，因此仅仅描述了信息的类别或分类，而具体的数值（例如计数或者平均值）会在后面的内容中讨论。
- 程序员加入团队的时间。
- 团队规模、团队优化和团队建设。
- 按复杂度分类并由程序员完成的任务。
- 程序员协同完成的任务或程序员帮助他人完成的任务。
- 特别紧急的任务，如修复严重的产品问题。
- 显示程序员超常的创造力、创新和主动性的任务。
- 延期的、失败的或者取消的任务。
- 程序员参与的项目、产品和产品领域。
- 花在任务上的时间。
- 花在会议上的时间，或者处理自己中断的事宜花费的时间。
- 客户发现的问题，以严重性和复杂度进行分类。
- 为了客户支持工作而进行联系的次数（电话、邮件或者聊天）。
- 购买或使用产品或特性的客户数。
- 试用了产品或特性，但决定不再使用的客户数。
- 取消或停止使用产品或特性的客户数。
- 维持、获得或直接竞争对手失去的客户数。
- 从产品或特性的改变中获益的现有客户数。
- 从产品、特性或者其他完成任务中获益的内部员工数。
以上仅是可使用在度量中的一些数据类型的例子。除了本书中提及的一些数据之外，毋庸置疑，也确实存在其他有助于程序员度量的数据类别。按一般原则，极有可能我并未完全尝试或考虑过许多潜在的数据。但对于有些数据类型，我本人曾经尝试或者深入思考过，而由于各种原因，这些数据并不是很有用或者存在更好的选择，因此本书中没有使用这些数据类型。下面是关于这些排除的数据类型的几个例子以及我排除它们的原因。
千行代码量（KLOC）
我们常常认为用代码行数（KLOC代表1000行代码）来测量程序员的效率是非常有用的一种方法，并且也有不少实例认为KLOC在估计技术和降低项目估计失误的工具方面是有用的，特别是对一些大型项目而言。但一般而言，我认为KLOC更像是活动而不是代码的度量指标。我很难将这个度量指标关联到明确的团队目标上，例如客户接受度、满意度或者产品质量。KLOC的另一个问题是，对不同的编程语言来说，它们没有一个统一的标准。比如，写1000行Java代码所花的时间和能力与写1000行JavaScript、XML、PHP或者Ruby代码是完全不同的（ 虽然理论上可以有这样的一个方法来进行跨语言的KLOC标准化）。最后，我认为程序员很难认为这个度量指标与其工作业绩或者成败有什么关系。从而，也就很难有效地使用KLOC作为一种手段就技能与贡献进行讨论。因此，出于本书中讨论的目的，我发现关注任务和基于复杂度的任务分类会比使用KLOC更有意义。
开发阶段的bug数量
bug数量肯定是评定代码质量的一种度量。但是根据我的经验，在开发阶段的bug不同于发布后产品的bug，由于存在太多的可变性，因此很难使得开发中的bug数量成为一个很有用的度量。开发过程中发现的bug的多寡会随着测试人员的数量、测试的深度和代码在开发中的成熟度而波动。如果我们在开发周期早期就开始对一块复杂的代码进行彻底地测试，会发现许多bug，但是这并不能告诉我们什么。也许会有人认为确实存在这样一些bug，如果bug是在程序员认为功能已经实现且完成单元测试的情况下发现的，它们可以成为有用的度量。但是我发现，在实践中，这项指标不太一致，也很难下结论。最后，我认为我们仅需保持关于任务的复杂度和完成这些任务所花的时间的度量，它已经包含了充分修改开发bug的时间，否则代码就无法发布。如果程序员制造了许多bug，其结果就是完成任务的时间更长。对于同样复杂的工作，花费时间更少的程序员一般更井然有序且产生的bug数目也较少。
产品收入
产品收入（毛收入或净收入）是商业规划和产品规划中的一个关键部分。我们建造什么产品，新增哪些特性，哪些问题值得花时间去修改，都依赖于财务分析的结果。在大多数情形下，软件开发的预算与产品收入有直接的关系。事情本该如此。然而，如果把产品收入作为软件开发流程中的度量，去衡量程序员和团队的成功与相关贡献，我认为这是有问题的。首先，很多软件根本就没有收入（开源项目和内部项目就是两个很好的例子）。即使存在收入，这也不总是与软件和软件开发团队的工作直接相关。它们广泛地依赖于折扣、不同销售人员的能力和更多的因素（包括国家或全球经济）等。另一个重要的问题是，将金钱作为度量，很容易转移注意力和带来误导。人们会变得更关注金钱，而不是度量的目标和意义。比如，每个客户需要为新的iPhone应用程序付费2美元，如果今天有1000个人购买，从许多方面来说，客户数比2000美元的毛利能提供更清晰、正面的阐释（2000美元无法让人留下深刻印象）。相反，如果你的公司本周仅仅成交了一个10万美元的订单，这个数字或许听起来令人印象深刻，但如果关注到存在那么多的业务却只签订了一份订单，这样的事实就需要我们更为关注。我个人的感觉是，产品收入的意识和理解收入预测如何驱动产品计划的决策对软件开发团队来说是有用的。但是，作为软件开发团队工作进度的度量，我更愿意测量特性的交付、试用用户到客户的转换率、产品bug数量，并且对用户数和使用量保持关注。
总之，探索新的数据类型并尝试使用它们不会带来损失。我们应该乐于试验新想法。也可以相信，其中非常有用的、合理的那些数据会显现出来，而剩余的部分可以舍弃。