Tom DeMarco, of Peopleware fame, wrote a book called "Controlling Software Projects: Management, Measurement, and Estimation". He has, in some ways, rejected hi

Tom DeMarco, of Peopleware fame, wrote a book called "Controlling Software Projects: Management, Measurement, and Estimation". He has, in some ways, rejected his ideas in that book. In this article, "Software Engineering: An Idea Whose Time Has Come and Gone?" http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf http://www2.computer.org/cms/Computer.org/ComputingNow/homep... he states: "My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. 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." The tl;dr of his article is that the software projects that require tight cost control are the ones delivering little or no marginal value. That is, "To understand control’s real role, you need to distinguish between two drastically different kinds of projects: ■ Project A will eventually cost about a million dollars and produce value of around $1.1 million. ■ Project B will eventually cost about a million dollars and produce value of more than $50 million. What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests 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?" I believe this as well. If the value of software we're writing is so low, it's probably not worth being written. The high value stuff isn't worth more than a cursory (e.g. Agile "Points") estimation. The other thing, which he doesn't touch on the article, is that in order to shrink the "cone of uncertainty" (http://construx.com/File.ashx?cid=1649 http://construx.com/File.ashx?cid=1649) you must put more and more effort into actually "solving" the problem. Rarely do estimates consider the time it takes to estimate (requirements docs, interviews, etc.). Ultimately, if you follow the line of reasoning all the way out, perfect estimation requires you to solve the problem and all you then estimate is precisely the amount of time it will take to type the code you've specced out. Of course, what you don't have an estimate for is all the time it took to arrive at your estimate. And thus, the folly of software estimation is revealed. (edit: Lack of blockquote is quite annoying, apologies for the messed up styling)