In my previous article on this topic, I had given an scenario which justified the use of the decompiler. I have now remembered a much better example.
A customer had problems after upgrading Weblogic 8.1sp2 to 8.1sp3. His JSP - which was rather large - suddenly stoped working with ‘method exceeds 64K’ messages. The JSP itself hasn’t changed between the versions.
The obvious suggestion here is that BEA’s JSP compiler started to generate larger code.
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.