Strapped to the Wheel

History repeats itself. First as tragedy, then as farce. This according to Marx, writing of the 18th Brumaire of Louis Napoleons. An unlikely anchor for my thoughts on software engineering, but apposite, as I shall argue.

Failures in software engineering remain common and the causes to which these failures are ascribed, tiresomely familiar. Inadequate requirements analysis. Inaccurate time estimation and resource planning. Ill thought out architecture. Poor configuration control. Insufficient time for testing. Each of these are well known and the technical means for addressing them are well established in the state-of-the-art. We fail not for obscure complex causes but for everyday reasons that are signposted on the first few pages of the textbook.

I think we can assume that the managers of most significant software projects understand the basics of software engineering and that, all things being equal, they are committed to implementing them. I rule out ignorance and ill-will. So, why are we strapped to this particular wheel? Why do we appear unable to avoid making these obvious mistakes?

These are I think the most significant questions for our discipline. The proverbial, much ignored 'elephant in the room'. My hypothesis is that the problem arises as the result of governance failures. That is, failures in the organisational alignment between business strategy and the means of implementation and in the structure of incentives that are intended to secure that alignment. If this hypothesis is correct, and I have only anecdote to support it, then we must step back from our immediate concern with new tools and techniques in order to address these failures. It implies that we must rewrite the software engineering agenda.