Just a Thought...

I‘m digging in the past on this one, but because my focus has been on design lately I think this applies. A long time ago someone I respect defended his position about a framework being complex using cognitive dissonance as a feature. Of course, I may be a bright guy but I‘m also self taught. That means I‘m not up on the latest from philosophy and psychology, but I‘m OK with that. I complained about there being too much cognitive dissonance from the perspective of audible dissonance. With my background in music recording, dissonance means two notes that sound bad together. They are discordant, or work against a musical chord. They stand out like a sore thumb and it can be painful to hear. It‘s an experience that is associated with pain and general badness. Imagine my surprise when this respected friend of mine said that cognitive dissonance can be an effective learning tool. I was taken aback, without any real response to that.

Thanks to Kathy Sierra's blog I was able to find out a bit more behind that statement. If you've followed her blog for any amount of time, you'd know our brains are equipped with a crap filter . This ingenious feature keeps our brain free of clutter and useless facts… most of the time. Some of the surefire ways to get past the crap filter include surprise, seduction, puzzles, and humor. If you reinterpret cognitive dissonance as surprise, then what my esteemed colleague said was true — from a certain perspective. However, there are good surprises and bad surprises.

Good Surprises

A good surprise includes things like saving a butt-load of time once you learn something. It‘s when the payoff is more than worth the effort you put in to learning the trick. Things like Ruby on Rails, and now my Java ActionPack have that good payoff for minimal effort. Another technology that I was pleasantly surprised with was the Expression Language that is now part of the JSP standard. It cleans up the code so that it looks nice without all the angle brackets and percent signs all over the place. Sure it has some rough edges, but it gets you most of the way there with very little effort.

Bad Surprises

A bad surprise includes things like finding out that you missed a small but all too important step so your code doesn‘t work even though it looks exactly like an example. Consider Cocoon Forms, and other technologies that try to be too smart for their own good. With all the different XML files you have to put together to generate the form, and the configuration settings you have to make to enable CForms, you‘ll wonder if the payoff is worth the effort. With all the knowledge spread out across several bits, and a little voodoo thrown in to boot, it‘s not clear what exactly is going on. Compare that with writing dedicated form handling code, and using a well written JavaScript library to help out on the client side.

Good Framework Design Practices

Cognitive dissonance might be en effective learning tool in writing documentation, but it is terrible in your code. If something doesn‘t make sense to you, if it isn‘t striking a chord with you, then that is your brain telling you that what you are trying to do is crap . Non-sequitur can be a useful way to break the ice, but it is a terrible way to learn how to use a library. The purpose of a framework is to be the binding to which all the pages of your application fit. It‘s to provide structure, and a way to help understand the application as a whole.

A good framework is one that becomes so sensible that you really don‘t notice it at all. No one part is emphasized above another. The whole thing works together as a unit. The framework should take care of the little things that the developer shouldn‘t be bothered with — but in a predictable and debugable manner. When something goes wrong, the framework should help by pointing out in as clear a manner as possible where it happened. The key word here is that the application and the framework become symbiotic. The framework needs the application to justify its existence, and the application needs the framework to get the job done.

The best frameworks are the ones that you don‘t feel like you are using, but are sorely missed when they are gone. Different libraries have differing levels of success in this area. Some examples of libraries I think excel in this area are Ruby on Rails, ImageMagick C++ bindings (a true example of generic code done right), and the JGoodies suite of Java Swing libraries. What sets them apart from the rest is how well they fit with the design of the language itself. There is a certain thinking process each language encourages, and when you find that sweet spot it is best to work with it instead of reinvent how its done. JGoodies demonstrated quite impressively how JavaBeans were meant to be used. The C++ interface for ImageMagick demonstrates just how nice and succinct C++ code can be if designed right. Ruby on Rails takes advantage of the features of Ruby in such a way where you will never be able to truly duplicate it on another platform. Even my Java ActionPack framework deviates from Ruby on Rails because there are things that Java just can‘t do, and there are things that have to be done differently to feel natural to Java developers. I‘d like to believe I‘m on the right track, and I like what I have so far.