Next... Design by Contract? (Please)

I was pleasantly surprised a few years ago when programmers (particularly open source programmers) actually started writing unit tests. XP is usually given the lion’s share of the credit, but I think that JUnit was the real reason: it was just enough structure to get people in, and had a perfect balance between simplicity and extensibility.

What I’d like to see catch on next is design by contract. Most people who’ve encountered it think it’s about enforcing modularity, or about making sure that derived classes respect the rules of their parents. What I like, though, is its temporal application: making sure that Version 3.1.2 of a class has the same externally-visible behavior as Version 3.1.1, so that upgrading is guaranteed not to break things. I’d particularly like this right now, as we’re banging our heads once more against “slight” differences between successive versions of what’s supposed to be the same damn library. The release notes for 3.1.2 of—let’s call it “Fred”, shall we?—don’t mention any backward-incompatible changes, but somewhere eight levels down in the call stack, something is passing an Element where it should be passing a string, and everything after that is blowing up.

Given pre- and post-conditions (a big given, I’ll grant you), a tool that checks an RPM, JAR file, or Egg against an existing installation, and reports discrepancies, shouldn’t be all that hard to build—the general problem may be undecidable, but even something conservative, that draws human attention to possibly problematic mutations, would go a long way toward making lives like mine a little better.

Update: Aaron Bingham’s presentation from EuroPython 2006.