August 25, 2011

On temporary patches

Once again the other side of a client-server link is broken. Our side works perfectly, but the peer sends in something incompatible with the protocol. This time it sends money value with 3 decimal places whereas there could be 2 at most. Our parser throws upon
and surprise ! They can't fix it. May be later. And it's definitely gonna take some time. Some indefinite time. Or forever. But they need the solution. Right now.

Reluctantly I go and remove the scale check, and add the abominable money rounding. It kind of works, but having that patch makes me feel uncomfortable. It doesn't matter that in case of a future problem we'll probably get away by pointing them to the case where they clearly state their wish. It simply doesn't feel right.

Worst of all, it's not going to be fixed. Ever. How about (I think to myself) having a temporary patch, a time bomb of a kind, which ceases working after, say, a month. Granted, not a good idea, for many reasons, but for a while it felt strangely good.

And it's dead simple to do in Python.
from datetime import datetime as dt

def fix_by(d):
  def _fix_by(m):
    def _fix_by_check(*args, **kwargs):
      if > dt.strptime(d, "%Y-%m-%d"):
         raise Exception("TOO LATE !!!")
      return m(*args, **kwargs)
    return _fix_by_check
  return _fix_by

def foo():
  print("ugly patch reporting")



Alan said...

The idea is interesting, but I'd take a slightly different - and safer - approach: instead of raising an Exception, use an assert statement, and be sure assert checking is disabled in production environment.

This way the "temporary fix" will only fail in your testing/qa/development environment, preventing possible rage outbursts from your customers.

Dmitry Dvoinikov said...

That's an interesting point. How about sending the responsible developer an SMS each time the check is triggered ? :)