A while back, I attended a presentation about a suite of software that allowed IT managers to track in some detail the progress of a development project, via static code analysis, a range of source control metrics and other magic. Bathed in these insights, management could instantly track the detail of what was going on and draw conclusions from it.

Having finished, the presenter stepped back from his detailed graphs in anticipation, perhaps expecting uncritical plaudits from the developers in the audience. We clapped politely, and shuffled uncomfortably. Nothing in particular emerged from the discussions beyond some vaguely-expressed reservations. Some things are best are left unsaid, but we all appreciated, instantly, that such detail was often dangerous in the wrong hands.

Why would a development team ever want to conceal anything from their management? Well, all organizations flourish by being, err…selective with information. Every department carefully manages information about what they are doing, so as to prevent misunderstandings. If the entire truth is told at a meeting of the board of directors, there is always a gasp of astonishment and mutterings of discontent. The same holds true of a development team.

What actually should happen in the course of creating an application is messier and more complicated than the perceived wisdom implies. The art of developing effective software generally relies on there being several phases. First, there is a wild, creative phase where anything goes, and there is a lot of architectural sketching, rapid development of prototypes and wireframes. Alternative technologies and algorithms must be assessed. There is a second phase where there is enough consensus that the team can work together to create a likely candidate application, which is close enough to the final product. At this stage, major U-turns can be considered, even if it frightens the project manager. The final stage is a disciplined and highly structured march towards release.

A healthy creative process can and should resemble chaos. I know of no metrics that can measure progress effectively during this phase. In fact, those disciplines that are essential to the final phase of a software project are complete anathema to the first phase. Issue-tracking, for example isn’t appropriate. Mock-ups and prototypes are supposed to have bugs. Developers have to be actively discouraged from too much attention to detail. Even source control can be overkill when an entire codebase is very likely to be, and should be, jettisoned at short notice. The way that you manage technical debt is quite different.

When we are asked by outsiders whether we invariably use TDD, source control, issue tracking, continuous delivery, Kanban, Scrum, quality metrics and so on, we nod assent, unblushingly, as though it were a simple question. The truth is more nuanced, and more difficult for the orderly and mechanistic mind of many in middle-management. It is best to manage what information gets outside the team, because truth is often complicated.