Software Project Metrics and Control: They Don’t Matter (Sometimes)

Software project metrics are not as important as we have been led to believe, and the field of software engineering has evolved to such a state as to almost be almost… over.

This is according to the eminent software engineer Tom DeMarco who, looking back at his 1986 book on the subject, Controlling Software Projects: Management, Measurement, and Estimates, now believes that our focus on control and metrics is wrong, and we need to completely reverse how we create and manage software, if possible (pdf).

The book’s most quoted line is its first sentence: “You can’t control what you can’t measure.” This line contains a real truth, but I’ve become increasingly uncomfortable with my use of it. Implicit in the quote (and indeed in the book’s title) is that control is an important aspect, maybe the most important, of any software project. But it isn’t. Many projects have proceeded without much control but managed to produce wonderful products such as GoogleEarth or Wikipedia.

To understand control’s real role, you need to distinguish between two drastically different kinds of projects:

  • Project A will eventually cost about a million dollars and produce value of around $1.1 million.
  • Project B will eventually cost about a million dollars and produce value of more than $50 million.

What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.

To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value? […]

For the past 40 years […] we’ve tortured ourselves over our inability to finish a software project on time and on budget. […] This never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.

via Coding Horror