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,
My answers are no, no, and no.
- 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?
--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
Community comments
Experiences are everything
by Jin Ming,
Re: Experiences are everything
by Amr Elssamadisy,
Re: Experiences are everything
by Erik Gfesser,
Paywall ..
by Richard Brown,
Experiences are everything
by Jin Ming,
Your message is awaiting moderation. Thank you for participating in the discussion.
Re: Experiences are everything
by Amr Elssamadisy,
Your message is awaiting moderation. Thank you for participating in the discussion.
Ming, I think you are missing the point of the article. Precise control is an illusion. Choosing projects where precise control is a requirement is missing the point because you are - by definition - creating software that has marginal value.
I may be wrong, but I believe the message of the article is that Tom DeMarco is saying he was wrong about control and measurement - for THEN and for NOW.
Re: Experiences are everything
by Erik Gfesser,
Your message is awaiting moderation. Thank you for participating in the discussion.
The ability to obtain what DeMarco refers to here as "precise control" of a project would seem to indicate that the project is of a low risk nature. Outsourced routine maintenance is an example of low risk project work. The decision to choose "projects where precise control won't matter so much" points to projects of a high risk nature. High risk projects generally have the ability to produce high value, whereas low risk projects generally do not. It is typically easier to control projects where risk is low because there exists more certainty. Pursuit of high risk projects should not be abandoned due to lack of predictability. At the same time, risk should always be managed. In DeMarco's collaborative book with Lister, the authors indicate that "risk management is project management for adults": www.amazon.com/review/RAAG2FULCL9EN.
Paywall ..
by Richard Brown,
Your message is awaiting moderation. Thank you for participating in the discussion.
Unfortunately this link appears to be behind a paywall now. It's a shame - I had pointed colleagues and clients at the insights in it.