software plumbing

I used to be impressed by the dexterity of the maintenance men who come around to fix things around house – about how neatly they accomplish things like fixing a leak or checking the wiring etc. Most of them have ability to make the things work with a quick fix, common sense and knowledge of the tools to use to fix something and they don’t make a mess.

This post is not about the house maintenance, but about putting together a software solution to the immediate need, having the knowledge to select the best tools for the job and to reach a quick solution, not building a house from ground up. In “Zen and Art of Motorcycle Maintenance”, there is a passage about making a replacement part made from a soft drink can for a friend’s expensive motorcycle – when you tell them that it is made from tin can, they may not allow you to put it in. I think it is a natural tendency to buy the packaged/branded/expensive product from a super store and expect that it is the best solution.

This is inspired by something I read today. It talks about “Actual Capabilities over Intended Use”. I loved the idea of using components for what they could do, not what it is documented to be able to do. Find ways to use components where they seem to be perfect and natural fit. I had once made a solution to execute a java component from a code which will be called by Unix script which will be called by java stored procedure which will be called by pl/sql procedure embedded in oracle report file. I had a natural choice path – I couldn’t use certain combinations because of certain system restrictions which leads me to the next natural choice.

Examples over Documentation: for anyone who has gone through endless pages thinking that “all this is good, but how do I do it” might identify with this. Having a Ten Minute Test is a great way to start using something by first seeing how it works – they don’t show you the user manual of a plasma TV in the shop, but they display it out front and give you a remote, may it should be the same with software also – give a chance to test drive. If I am not able to make something work, then I can go into documentation or even the next step – source code. Reading code is the final truth than reading a manual and wondering whether it meant what it said.