Expert-level problems
I’ve been teaching myself a lot of new programming languages and/or APIs lately (C#, HTML5, Cocoa, Adobe AIR). Something I’ve been thinking about a lot is expert-level problems. These are technical problems you encounter that you can’t solve unless you’re an expert at a particular technology. For example, here are some that I’ve battled:
* dealing with Unicode in Perl
* managing the thread-context ClassLoader in Java
* working with two different malloc implementations in C++
* making a standards-based webpage look pixel-perfect in IE
Expert-level problems are the bane of someone coming up the learning curve in a new technology. The biggest issue is that beginners don’t know how deep the problem is. Maybe it’s a little problem that you’ll be able to solve with a little learning, or maybe it’s a problem where you can sink a week of work and get nowhere.
I believe there’s no solution except to become an expert (or hire an expert). And, in my opinion, you can’t become an expert unless you’ve got a tangible goal and strong motivation to reach that goal (i.e. a job). When you’re just dabbling with a technology, it’s not likely that you’ll become an expert because you won’t have the time or motivation to dig to the bottom of those expert-level problems.
IMHO these expert level problems are the reason to seek out and use frameworks. Normally frameworks have been designed, implemented, and battle tested by experts in their field – for examples have a look at the many great frameworks published at the Apache Software Foundation and other communities. Sure, there will be always be some expert level problems that are not covered, but hopefully the framework will mitigate the issue or provide guidance to reduce its impact.
Jamie Goodyear Good answer, and nice plug! 🙂 I’ll take this opportunity to express a huge THANK YOU to you personally for your work on Karaf.
A framework is great if you’re an expert – it solves all of the annoying problems you don’t want to have to solve yourself (but you could if you had to). And they’re great if you’re a beginner and the framework covers your problem space, because it saves you tons of learning time.
The real danger of a framework is when you step into a problem that it doesn’t solve, and then you’re doubly screwed because you need to learn the problem and also how the framework functions at the periphery of that problem. That was the point of my Maven post (https://plus.google.com/109145929828138109979/posts/ZeV8vvgZzJc) a few days ago — when it goes wrong, you may as well give up all hope! A perfect example is the tag in Maven. Many people don’t know that Maven treats this as a suggestion rather than as a command. This is to solve the expert-level problem of inter-dependency version hell.
That’s not to say that frameworks should be avoided of course! On the whole they’re a net positive, but they’re not a panacea.