Tom DeMarco’s influential 1982 book “Controlling Software Projects: Management, Measurement, and Estimation” famously started with the aphorism that you “cannot control what you cannot measure”, in arguing for more metrics in software development. There is pushback against this notion, however, and DeMarco himself (pdf) has said he thinks it was written naively: “a curious combination of generally true things written on every page but combined into an overall message that’s wrong”.

The critique against management as measurement (e.g., Jorge Aranda‘s) stems from a belief that measurement implies a Taylorist approach to software engineering that is simply not applicable. Software construction is not widget assembly, and even in industrial assembly lines the notion of human workers as cogs has changed dramatically, most obviously as encapsulated by the set of philosophies called the “Toyota Way”, and now commonly called “lean manufacturing”.

The idea that a software team lead could sit in a corner office, enveloped by dashboards showing lines of code added per day, bugs fixed, etc. does seem silly. Clearly, a better approach would be to understand the team dynamics and their struggles – the role that the Scrum Master plays, for example. However, this isn’t to say that metrics aren’t supremely important. The lessons of big data and Google-style machine learning is that there are often messages hidden in the data that cannot be surfaced with individual, anecdotal experience. Consider a simple indicator like “lead time” (the time from a work item being created/accepted to it being closed/released). It can be very difficult to get a good sense for this in the aggregate, since developers spend so much time on individual items. It is only looking back on a cumulative flow diagram that spikes in lead time can be detected, and bottlenecks resolved.

I think the difference from Taylorism is that modern metrics are seen as complementary to hands-on, qualitative management, or pieces of  a software process improvement approach like Kanban. In Kanban, two key areas where this occurs are the principles of “Visualizing workflow”, often using a whiteboard with swim lanes, and “Managing Flow”, which uses lead-time and work in progress measures. The key point, though, is that these are two of the five core principles, the others being “limit work in progress”, “make process policies explicit”, and “improve collaboratively”. You don’t manage on metrics alone 1. The metrics drive the self-improvement process but cannot replace in-depth understanding. In short delivery cycles like Scrum or XP advocate, this is much easier to do, because the ability to tweak the process occurs much more rapidly than in longer-iteration approaches, as Jim Highsmith pointed out.

1. Let us stipulate that there are endless examples of low-maturity teams out there whom no technique will help.