Its also worth noting that although I agree (and am very familiar) with the XP philisophy on this one, I think you'r mis-interpreting it slighty. Considering the timjeline for payback on a code investment now is important. But its also important not to read that as 'do nothing other than the bar minimum'..
One might consider that if he did use the general mechanism, he stays in line with the product evolution, and therefore makes a saving in the long term as he can benefit from additional work others do on improving that mechanism...
That is a reasonable certainly.
Also. Given that the mechanism already exists and is a peice of piss to use, then surely its easier in this case than 'doing your own thing'?
Therefore, as I mentioned earlier, unless there are *real* performance worries or very high volume, perhaps it makes more sense to consider the existing solution...
I guess I'm not syaing which is best, I just think Branimir is being a bit 'black or white' on this one.
Its also an XP implied-ism, that one should also not re-develop, avoid, functionality just cos its not perfect. If it will do the job, it will do.... refactoring only need come in as and when a problem arises (which it may never)..
