DeMarco Reflects on 40 Years of Software Engineering Evolution

Posted by Deborah Hartmann Preuss on Aug 20, 2009

Sections

Process & Practices,

Architecture & Design

Topics

Agile ,

Methodologies ,

Customers & Requirements ,

Leadership

Tags

Value & Metrics ,

Criticism ,

History ,

Waterfall ,

Management

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

1. Back to top

   Experiences are everything

   by Ming Jin

   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...

   
   
   Seems the wisdom to determine whether a project needs precise control or not is everything. But where does it come? I think it's based from experiences of different types of projects.
   
   If you're a rookie, you shouldn't refuse those projects you should take precise control. Then you can gain the experiences yourself...

   Reply

2. Back to top

   Re: Experiences are everything

   by Amr Elssamadisy

   
   If you're a rookie, you shouldn't refuse those projects you should take precise control. Then you can gain the experiences yourself...
   

   
   
   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.

   Reply

3. Back to top

   Re: Experiences are everything

   by Erik Gfesser

   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.

   Reply

• Older >