Problem Driven Exploration

Who could resist the charm of shiny new toys? The least is a few seconds distraction. At best, we just couldn't get them off our minds, we just can't not reach out and touch them. I guess that inner kid in all of us just would never go away. Always the explorer of new things. And guess what, this could be a good thing.

20-something Java developers like me are easily intrigued by the newer and the not so new toys the past months brought like RoR, scripting languages on the VM, REST, etc. Of course with the intrigue and the curiosity, comes time and effort investment. The curious "kids" invest in the hype, well at least speaking for myself. But how productive are these exploration activities? Would a Java developer be better off concentrating instead and improving his handles on the "toys" already in his command?

Point is, exploration has the potential for innovation. But, blind exploration would more or less rest that amount of potential on luck. And unsuccessful effort is tiring and wasteful. What we want is to lessen our dependency on luck and drive this inner yearning to a direction that would make us successful.

This brings me to one possible solution to this: limit exploration to possible solutions of pre-determined problems. Problem driven exploration, as I would like to call it. Simply, look for answers, not questions for those answers. Tools solve problems. It's really not very helpful if you have a tool but have no problem. And problems differ from one person or organization to another. If you have no personal problems with your Java MVC framework, then why bother with RoR? But, if XML is becoming a hassle for your specific situation, then time to explore on stuff like YAML and DSL's perhaps.

In this light, I guess it's very important how an individual or organization keeps their list of problems specific to their situation (last four words very important). For organizations in particular, I guess they would be doing themselves a favor if they are pretty transparent with their pin-pointed difficulties to their developers. Who knows, some kid in a tiny department might have all the zest to explore a solution for them?

Never let the inner kid in you grow old and boring. But take advantage by strategic control of that phenomenal behavior.