Dealing With Breaking Software Changes

Brad Abrams points to a great resource for defining and controlling changes which break existing software. Changes to any interface are a huge deal to any users of that interface. Careful thought needs to go into what you change, how you change it, and how you push those changes downstream. Brad's note about Microsoft having formal criteria for what constitutes a "breaking change" should be taken to heart by folks who deal with interfaces. I haven't finished reading the Word document from the link Brad points to, but the first few sections are very thought-provoking and have some great detail. This sort of stuff isn't ground-breaking concepts, but it's important and should be thought about. Scott Meyers talked about this same sort of thing during his presentation at SD West last year, and of course Steve McConnell hits this hard in his Code Complete, 2nd ed.