Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

FoxtrotUniform (5412)

FoxtrotUniform
  (email not shown publicly)
http://www.cs.sfu.ca/~mjolson/personal/

Just another vim-using (Perl|C|Haskell|Scheme)-hacking sesquipedalian academic graphics geek,
Tuesday November 02, 2004
10:32 AM

An Ongoing Review of Code Complete 2: Part 1

[ #21655 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 [bookpool.com] for programmers.

    He's got other [bookpool.com] books [bookpool.com] on the subject of managing requirements.