Coming soon, honestly, thoughts and reflections upon the excellent feedback from the CSS article. It was all much more thoughtful than the all-out flamewar I was expecting!

Recent discussion on the Java Forums about the Hibernate framework got me thinking about attitudes to frameworks in general.

The right way to use a new framework:

1. Already know underlying techologies.
2. Read the feature list and confirm that it provides benefit to your project.
3. Read the documentation in detail.
4. Build your application.
5. Profile your application.
6. Analyse and fix problems arising in use of the framework.

If you don't know the underlying technologies properly you won't be able to fix problems resulting from the Law of Leaky Abstractions. For example, if you don't know SQL you won't be able to diagnose the annoying cases when a badly phrased HQL query slips through the parser and generates syntactically invalid SQL.

Know the features. This ought to be obvious but it does happen that people elect to use a tool because they've assumed that it has some particular feature.

Read the documentation. You can't wield a framework properly unless you know how it's supposed to work. For example if you're trying to use Hibernate and you don't know the meaning of association directionality, cascade rules, or about the existence of the action queue, you are going to cause all manner of havoc.

Once you have built an application it will, typically, contain a few performance glitches. The right way to fix these is to profile the application, find out where they are, and address them. The wrong way is to hypothesize a rationale ("Hibernate is crap") make a fix ("replace it with straight JDBC") and then find you still have the problem ("Hibernate made our code slow even when we removed it !")

Frameworks do have bugs in them sometimes. If you're using the framework in an unusual way, or more extensively than is usual, you might brush up against some of its limitations. If you do so, find and fix them. It's rarely as difficult as you might expect and it's almost always better to do this than try and create equivalent code from scratch while building in your own unique set of limitations.

The wrong way to use a new framework:

1. Decide that it can save you from learning the underlying technologies.
2. Build your application.
3. Be baffled when behaviour and performance are erratic.
4. Badmouth the framework.
5. (Optional) Castigate anyone who likes the framework.

Frameworks can't substitute for knowledge. Hibernate is not a replacement for understanding JDBC and SQL.

If you haven't understood the tools you were using to build your application, and if you don't use profiling to investigate any unanticipated performance problems, your problems can be fairly and squarely blamed on your own complacency, not the choice of framework.

Slagging off the framework as the cause of all your problems merely highlights your own incompetence to those who have had success with the same system. It's not a great idea to advertise that you're a bad workman.

Some people, especially those who read an enthusiastic review on one of the skimpier "technical" sites flip from evangelist to zealous enemy as soon as they're bitten by their over confidence. On the basis that the friend of my enemy is my enemy they'll attack anyone who supports the tools they despise. This is a useful trait because it makes them easy to spot for exclusion from your team.

In summary:

Coding the tools from scratch is almost always more fun. Using someone else's system is often frustrating because you have to adopt their design philosophy when interacting with their framework. Nonetheless the NIH attitude has proven time and time again to be the downfall of projects. Professionals use frameworks instead of coding from scratch. Remember not to whine too much when the bastard thing gives you a class cast exception for reasons that are an affront to humanity.