Developers under thirty may not know the name, Tom DeMarco, but if you ever drew a paycheck from a large organization, you’ve felt his influence. When your boss said “You can’t control what you can’t measure”, he was channeling Mr. DeMarco.
I can think of no single individual who has had a more pervasive and decisive say in how we manage software development. Corporate CIOs, IT directors, and senior architects have listened to him prescribe “best practices” for more than 30 years. So when he says “I was wrong all along” … it’s like hearing Robert McNamara confessing his tragic mistakes. You feel you knew it all along … but it hits hard to hear him say it.
In “Software Engineering: An Idea Whose Time Has Come and Gone?”, Mr. DeMarco confronts his life’s legacy -- his insistence that precise planning and intense monitoring are essential to project success -- and condemns it.
Let’s not go overboard. He isn’t against measurement (and neither am I). If you can measure it … and your measure bears a well-understood relationship to the good or evil you want to assess … and the cost of measurement is reasonable … then measure it.
But putting control and measurement first utterly obscures what really matters: the potential value of the project and the forces that can determine the timing and success of the project. Indeed, planning and measurement can … and often do … actively impede success.
Re-blogging is an etiquette violation. I’m doing it anyway because I fear readers unfamiliar with Mr. DeMarco will miss the many gems in his short and sweet mea culpa. Some juicy quotes to entice you.
“Strict control is something that matters a lot on relatively useless projects and much less on useful projects”
“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.”
“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.”
“Consistency and predictability are still desirable, but they haven’t ever been the most important things. The more important goal is transformation.”
“You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product.””
Before we get all smug about agile and the disaster that is “Waterfall Design” … I want you to think a solid few minutes about whether you are susceptible to putting engineering practices in front of something more important.
His critique seems to target only an overweening attention to planning and control. That just happens to be his personal road to perdition. He aims at a wider target.
Look at the title again. He asks is “Software Engineering” an idea whose time has gone? If you find that TDD or DDD or BDD … are what you talk about first, are you making the same category of mistake? How can these practices – whatever their merits - be more important than the value of the project and whether it is delivering on its promise? If, for example, you believe that there isn’t great software without unit tests … have you fallen into the same trap?
Imagine the courage it takes to come to such conclusions about your life’s work? I salute Mr. DeMarco. And I hasten to add that his writing was always more nuanced and more useful than his own harsh self-criticism suggests. He remains well worth reading … more so in the light he shines from this vantage point.
Aside: I learned about this article from a Kent Beck tweet. You’ll find the endlessly fascinating Kent Beck blog here.