The Death of Software Engineering?

Tom DeMarco recently made quite a stir with an article in IEEE Software (July/Aug, 2009). Despite his own history as an influential thought-leader in software engineering, he now suggests that perhaps the very idea of software engineering has outlived its usefulness. The value of control, furthermore, depends inversely on the value of the project itself. In other words, “strict control is something that matters a lot on relatively useless projects and much less on useful projects.”

Needless to say, the idea was controversial, and unleashed a torrent of letters in response. There has long been a creative tension between software development as a rigorous scientific discipline, and the more romantic notion of software developer as artist or craftsman, with passionate debate on both sides. My own viewpoint tends to fall somewhere in the middle, and I found DeMarco’s article especially moving, because it suggests a willingness to abandon orthodoxy in favor of pragmatic reality.

One aspect of conventional wisdom that DeMarco challenges is his own earlier statement that “you can’t control what you can’t measure.” It’s a catchy statement, and oft-quoted. Certainly, it’s hard to argue against measuring the critical parameters for your project if you have a practical means of doing so. But life is full of counter-examples as well. As my wife and I interact with our daughter, we establish guidelines and boundaries. Her compliance isn’t measured in any scientific way, yet she’s not “out of control.” Similarly, I’ve experienced success in guiding projects without measuring every aspect of the outcome that is important: Typically cost and schedule are measured quantitatively, but code quality may be more subjective. Metrics can be useful, but not necessarily essential, depending on the type of project.

I am reminded of a linguistics professor I heard lecture in the 1980s (I wish I could remember his name -- it was a great lecture!). He was challenging the opinion held by many that we don’t really know something unless we can put it in words. As a counter-example he cited an instance where his young grandson went missing. He knew vividly what the boy looked like, and would have recognized him in an instant. Nevertheless, it was difficult to describe him precisely in words for the missing persons report. It often seems to be the case that we know something when we see it (high-quality software design, for example), even if we cannot quantify a metric to prove our case.
I hope the end result of Tom DeMarco’s skeptical article will be greater openness and flexibility. As software developers, we have many tools at our disposal. We can be craftsmen and engineers at the same time. Embracing one end of the spectrum doesn’t exclude us from the other.