All right, let's get this show on the road.
Code Complete 2 is a tradesman's guide to software construction.
Steve McConnell likes the construction metaphor for software development. McConnell likes it so much that he's devoted a whole chapter to explaining why it's good and why other metaphors ("Software penmanship"; "Software farming") aren't. (He says a few good things about incremental development – "Software accretion" – then drops the subject.) This all rubs me a bit the wrong way – I'm an "agile methods" fanboy – but I'm willing to chalk that up to my own youthful sense of invincibility and my lack of experience with titanic Big-Company software projects.
Most of the meat of the first four chapters is in Chapter 3: "Measure Twice, Cut Once: Upstream Prerequisites". At first reading, this chapter is a giant handwave about requirements and design. McConnell's writing for implementing programmers on large projects, so instead of telling us how to design a piece of software, he tells us what to look for in a good design. To me, it looks like he's setting up excuses for failure: he doesn't just ask for a spec, for example, he asks for reasons why other specs weren't chosen. That's reasonable among "software architects", but it's out of place when McConnell has just told the reader that, in effect, "specifying the system isn't your problem".
You might get the impression that I don't like Code Complete 2; that's not quite true. I don't like the first part of the book, but I'm keeping an open mind about the rest of it.
At first reading, this chapter is a giant handwave about requirements and design.
I'll have to re-read that chapter to see what was said, but it seems to be a bit of handwaving on requirements and design is keeping within what the book is about: writing code. Not designing systems. Not managing user requirements. Its about putting the pen to the paper, so to speak. Think of it like Elements of Style for programmers.
He's got other books on the subject of managing requirements.
