Good Exchange Specifications are messy

Mar 9, 2012

It’s a paradox of software code: while we all strive to produce beautifully organized code, the hallmark of code that’s actually had a lot of exposure to the real world use is that it’s messy. people have had to fix specific things that are wrong, but they’ve tried, as much as possible, to leave all the things that are known to be fit for purpose in place. While we all spend time pushing back against the messiness with refactorings and design patterns and complete redesigns, we can only push back against the messiness - it’s going to keep coming back at us.

Part of this is to understand that there’s different kinds of messiness

  1. Messiness that is created by handling special cases
  2. Messiness that is infrastructural - the whole organisation of everything is a mess
  3. Messiness that is decorational - the code itself is in a mess

It seems to me that there’s a logical conclusion to this, one which people are really reluctant to draw: the less special cases in the code, the less certain we can be about how useful it is on the grounds that it’s not been in regular use.

I think this applies to standards as well - the cleaner the standard, the less exposure to the real world it has.

So next time you hear people complaining about how HL7 v2 is all over the place, or that the Snomed heirarchies are a mess, stop and think: maybe, that’s because they’ve had a lot of actual use in the real world, rather than that they are poor quality standards that are not fit for use. There’s only one way to find out - try and actually use the relevant standard.

 

 

  • Messiness that is decorational - the code itself is in a mess *