DeMarco Reflects on 40 Years of Software Engineering Evolution

On the 40th anniversary of NATO's "Conference on Software Engineering," where the discipline of software engineering was first proposed, Tom DeMarco paused to reflect on the discipline's evolution, including his role in influencing its initial direction toward metrics. The author of the much-quoted "You can’t control what you can’t measure" now wonders whether this orientation has distracted us from the real point of computing: "The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business." His conclusion, under the title "Software Engineering: An Idea Whose Time Has Come and Gone?" [pdf] appeared in the July/August edition of IEEE Software magazine.

In this article, DeMarco defines "software engineering" as follows:

The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.
--Tom DeMarco

DeMarco is probably better known to Agilists as the author, with Tim Lister, of the 1987 book Peopleware, on the human aspects of our business. But how many of us are aware of his influential 1982 book "Controlling Software Projects: Management, Measurement, and Estimation"? DeMarco began his article by looking back at this book:

In my reflective mood, I’m wondering,

• Was its advice correct at the time?
• Is it still relevant? and 
• Do I still believe that metrics are a must for any successful software development effort? 

My answers are no, no, and no.
--Tom DeMarco

Reflecting back on this book, he saw much truth, while also noting that this discipline operates differently than natural sciences like physics: "software development ... metrics ... must be taken with a grain of salt." He went on to consider the book in relation to the concept of delivered value, leading him to now suggest that:

"... the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.   To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?"
--Tom DeMarco [emphasis added]

Before concluding, he briefly suggested a more suitable incremental management approach whose spirit will ring familiar to Agile teams and their customers.

Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to control them, no matter how assiduously we apply ourselves to control.
--Tom DeMarco

Related Editorial

Related Vendor Content

Infographic: Just How Big is the Nerd Economy

Five Key Practices to Agile ALM

Application Performance Management Buyer's Guide

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile workshops and training

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.