Sunday, August 15, 2010

Can we measure *anything* in software teams?

Code complete, a great book about software construction, suggest starting with at least some measurements:
  1. number of lines of code written
  2. number of defects detected
  3. number of work months
  4. total dollars
Then the measurements should be standardized between projects and only after they are implemented across the company, they should be taken into account in understanding the process of development. These should influence your thinking about the process and what do the measurements improve. An example might be intoducing the continuous integration game into your hudson server. This will for sure make people optimize for this. In one of the projects we have set it up so that it takes into account checkstyle, PMD violations, broken builds, successful builds, tests failing and so on. Even though the game is still missing a couple of meaurements that could potentially be useful (such as: code coverage measurements, +10 points for each additional percentage of previously uncovered code or something to that extent), it immediately had an influence on what ended up in the repository. People tend to optimize for whatever measurement you are taking. This is a fact of life and I think that Joel is somewhat right in his judgement that the extrinsic motivation replaces an intrinsic one. Is there any way that we can measure things and still keep clean of the "people optimize for the measurement" thing?

No comments:

Post a Comment