Monday, September 15, 2003

Software
The Pragmatic Programmer, by Andrew Hunt and Dave Thomas, is one of my favorite books about the of programming. They distill their advice down to about 70 tips, but three really stand out for me, and I've made them part of my philosophy about my trade.
  • Don't Live with Broken Windows
    Don't leave broken windows (bad designs, wrong decisions, or poor code) unrepaired...Don't let entropy win.

  • DRY - Don't Repeat Yourself
    Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

  • It's All Writing
    Treat English as just another programming language.

The combination of the last two is particularly powerful. For years, I've struggled with how to write effective documentation that's both concise and complete, and can be maintained along with the code. Putting those two ideas together helps a lot. So I try to let the code say what it says (this is how it's done), let the UML diagrams and other pictures say what they say (this is what the pieces are, how they're structured, and how they relate), and glue it all together with just enough prose (this is why it is what it is). A crucial tactic in this is to make the software as self-describing as possible - by putting as much application-specific detail as possible in metadata and making the code as simple and clear as I can.

A lot of developers I know believe that all you need is the code, and all you have to do is read it in order to understand the application or system. I disagree; I think that only indicates how immature the discipline of software development really is. I think we need to think of ourselves as writers, not coders, and understand the whole process as a continuum of authorship. And what we produce is writing. And we correct it, enhance it, refactor it, reuse it, and recast it for the whole of its useful life. And we should take pride in making it as easy to understand as possible. The macho attitude of "just read the code" is the attitude of intellectual adolescents.

Critical documentation that is out of date is, of course, another form of broken windows. Don't let entropy win.

Other good books on the craft:

The Practice of Programming, Brian Kernighan and Rob Pike
Facts and Fallacies of Software Engineering, Robert Glass
Refactoring, Martin Fowler
Peopleware, Tim Lister and Tom DeMarco

and the all-time classic:
The Mythical Man-Month, Frederick Brooks - I recommend re-reading “No Silver Bullets” at least once a year.

I should read Jon Bentley's Programming Pearls, too, but I just haven't gotten to it yet.

Honesty compels me to admit that Knuth's The Art of Computer Programming trilogy is still a little over my head. I've set myself a goal of reading (and understanding) it all by the end of the decade. I have no doubt that it will still be relevant.

No comments: