Just listened to a great interview with Dan Appleman over on Hanselminutes

That spring, I treated my self to an MP3 player, a Creative Zen Vision:M.  Why I picked a ZVM is food for another post, but it's opened up a new world to me.  The world of podcasts.  My podcast listening typically falls into two categories:  programming related and NPR shows.

One of the programming podcasts that I listen to on a regular basis is Scott Hanselman's Hanselminutes.  His stuff is very good.  He gets to interview a lot of cool people in our world.  I just listened to his 11/29th interview with Dan Appleman.  They talked about software architecture, but they concentrated on the human side of architecture. 

Dan talked about what should go in a software specification.  He mentioned something that I occasionally do and that is that the spec should clearly list what it doesn't do.  A good spec will cover what it will perform, but you usually don't see specs that clearly list what will not be performed.

That makes so much sense.  It's important to list the scope of the spec, but it's just as important to list the limits of the spec.  We all make assumptions, that's just human nature.  I've been in situations where code was delivered and people asked for feature "B".  "B" was never specified, but since the code included feature "A", they had just assumed that "B" came along with "A".  Then you have to go back to add "B" and hope it wasn't too expensive to add after the fact.

When you list what the spec wont do, it forces the client to think a little more about what they want.  If you want something additional, it's lot easier (and cheaper) to add that feature before the code has been written than after.