Tears

My father was a scholar of modern Jewish history, specialising in the history of Jews in Poland. His interest was to introduce a more nuanced understanding of the role of Jews  in Polish society. In describing Jewish histories he characterised the bulk as presenting what he termed a 'lachrymose' or tearful account of Jewish experience in which misery was piled upon misery and oppression upon oppression. Now, for sure, Jewish history has more than its fair share of misery and oppression, but to present it solely in those terms, he argued, is to fundamentally misunderstand its character. I realise that discussion of Jewish historiography as a segue into some comments on engineering may appear strange (and, on a personal note, I am painfully aware that the only person to whom this would appear entirely natural is absent) , but please bear with with me.

My contention here is that we have a lachrymose account of software engineering, in other words that our account of the discipline is dominated by a focus on bugs and errors, and framed by project failure. Now, as with my odd analogy, software engineering has much more than it's fair share of problems to contend with, but to define the discipline solely in terms of its ability to mitigate failure is to misdirect ourselves. This 'negative' mindset is deep within the structure of our discourse. The introductory texts of software engineering focus on the failure of programming practices to scale and on the discipline necessary to reduce the costs of error detection and removal. The emphasis is on process as a tool for avoiding cost and schedule overruns. The (scientifically dubious but nevertheless ubiquitous) Standish Reports that present dire statistics for project failure, open many presentations. Even agile development is justified in terms of the failures of conventional development rather than on its own terms. Software engineering must be one of the few disciplines in which risk is defined not as the probability of an adverse event occurring, to be set against the probability of success, but as the adverse event itself. A strange usage reflecting a negative outlook.

I wish to argue for a subtle but important change in the way we talk about software engineering. Instead of concentrating on how software engineering serves to avoid problems we look at instead at how it supports positive outcomes. In other words we talk about user focus, the capacity to respond to change, the ability to deliver more extensive functionality, rapidity in addressing requirements, and so on. If this is adopted consistently I suspect this may drive research agendas, rebalancing, for example, between testing and analysis (relatively well worked areas), and design (still relatively neglected). A change in discourse might also enhance the  positioning of software engineering with respect to its competitors on the research funding scene. It should also allow us to take credit, as a discipline, for the positive achievements in computing, rather than bearing the sole responsibility for its problems.

There is an old story that when a spacecraft lands on the moon it is hailed as a triumph of science and when it blows up on the launchpad it is mourned as an engineering failure. Like many such stories it has a ring of truth.