You don’t normally get to hear the near-famous people fighting. Usually, they have their responses polished or they agree to disagree. Not so in this recent podcast on Google’s AutoLink from the ITConversations. In this one, both Robert Scobble and Cory Doctorow lose their cool and start really throwing words around without listening to each other. Which is a pity, because it would have been nice to see them actually give in a point or two to the other side.

Andrew Savory(?) writes that if you have to stoop to decompiling a product to figure out a problem, it is the vendor’s fault because they chose not to supply you with the code and documentation. So, if the vendor does not provide the source and the particular functionality is not well explained, it is completely vendor’s fault. I wish it were so simple. I do agree that in the ideal world, every feature would be documented and/or working 100% correct.

Mike Clark is looking at automatic first-line support by building some auto-support functionality straight into the program. It is an article worth reading. One thing that the article does mention - in a somewhat negative way - is the ‘secret’ checklist the developer would go through to troubleshoot the application. He suggests that the ‘secret’ checklist can be automated by the tests. In my own experience (with BEA weblogic support), the checklist is usually more like a branching tree of decisions that would be fairly hard to encode as any simple set of JUnit tasks.

We have Design patterns, Analysis patterns and even Maintenance patterns. But where are the Technical support patterns ? Oh, we have plenty of horror stories, but nobody seems to be drawing lessons out of them. The nearest I found was the Maintainability pattern language, which is worth a read. But even that document is too generic to be useful in the trenches. I am still looking. If I don’t find anything, I will try to codify my own experience, but surely somebody else has done at least some of it already.

IBM has refreshed the IBM has refreshed the software. Goodness of their heart? Not so fast. Apparently, HeapAnalyzer used to be an internal IBM support tool. Paid customers who had problems with IBM JVM would take the memory snapshots and IBM support would use the tool to do the analysis and recomendations. Now - with the tool available to the public - IBM support will no longer analyse customers’ memory leaks.