This post is the first of a few summarizing and commenting on key estimation principles that McConnell covers in the book.
As my title suggests, step zero: count something ... count anything. Count features, functions point, user stories, use cases, web pages, GUI widgets... count what you can. It'll take some work to get from that count to a useful heuristic for estimation, but it's way better than the all-too-common practice of estimating by licking a finger and holding it up in the air. Hmmm ... 7 knots, from the north-west.
Steve spends many chapters exploring what to count, when, and how; who should do the counting; and what to do with the totals. But the premise is that "take a SWAG and double it" is not only unreliable, but it's indefensible. How can you explain an overrun or ask for more resources if there's no process to justify your numbers? There's no way anyone in your organization can plug your "gut" into a spreadsheet in a useful way, so you're perpetually at a disadvantage in negotiating to ensure positive outcomes.
Another vulnerability in the gut-feel approach is that -- even if the manager or programmer who makes the gut estimate is right on the money -- she can only be right on relative to the scope she is imagining to be on the table.
In many organizations, scope is not made sufficiently explicit to guarantee a proper understanding up front. Thus the "counting" part of the estimation process actually brings new specifications to light regarding the project being estimated. A couple of iterations of this process, and a lot more is known by all parties. More knowledge generally leads to less risk and more predictable outcomes.