In particular, the Project Specifications section really impressed me. I've always said that if you can define the problem well enough, it's already solved. And that's sort of what this section is talking about, even though it approaches the subject from the other angle. McConnell's point is, I believe, that before setting out to do any work whatsoever - including planning - it's vital to define the problem you are trying to solve in as much detail and completeness as possible. This is the most effective way to mitigate the potential loss of progress should some aspect of the solution be found to not adequately satisfy a business requirement. It's also the best way to proceed to the planning stage.

I can relate to his message in two recent events. One was at work, where specification changes nearly quadrupled the amount of work I had to do to complete a project. The second event was when I started designing tiles for Balloon Ghost. Although I'm working effectively and quickly on this game, I'm realizing that I'm spending a lot of time redoing things like drawing the map tiles. The reason I'm wasting time on them is not because I have trouble using the software - it's because I haven't taken the time to define the problem well enough, which in this case would be the environment where Ghosty is jumping around in. Instead of having a clear vision and drawing the tiles to match it, I'm scrambling to build a world for Ghosty to live in at the last second and relying on patterns to convey visual information. It's not a good place to be in, and had I read Code Complete and heeded its advice earlier, I would never have found myself in such a place at all.