This is a repost, from an old blog of mine. Originally posted on 9 March, 2006.
I finally figured it out. I’ve been struggling to work out how to explain to various framework authors and supporters why I think what they are telling people is not right, or why the frameworks are flawed, with very limited success.
Today, though, it all crystallized.
See, I’ve been trying to use my psychology studies. I told Ed Burns – of JSF – that JSF simply presented too many concepts for the average human brain to understand. He said that plenty of people do understand it, and he’s right, of course (even I understand it!), but I still stand behind the statement that the framework itself is not presented in such a way that ordinary humans can avoid having to “sink or swim” in JSF concepts.
When people “sink or swim,” they end up having to endure this moment of transformation, where all of a sudden, everything comes into clear focus and understanding is granted from on high. It works, I guess, but it’s also frustrating for people who can’t commit the time and energy to working with a given framework.
So my answer to JSF is to either change the number of concepts one has to master in order to use it (which can’t really be done), or manage to present the information as if you’re talking to idiots who’ve been hitting the bottle or bong quite heavily.
However, the pattern with JSF has presented itself with other frameworks, too. EJB3. Wicket. RIFE. JPA. Web services. JAAS. JMF. JavaMail, for crying out loud. The pattern never ends.
The problem isn’t that the frameworks or APIs are flawed. They really aren’t, by and large. (There are a few that are, and I won’t point them out, because that erodes the Struts that our world is built upon. We have to get Webwork done, after all, to be part of Web 2.0.)
The problem is that the people who write and document these frameworks don’t realise that people are, after all, really not that bright.
I have a friend who works on a fairly impressive system, that has a huge sales cycle. What his company does is work with the customer for a long, long time, basically doing stuff for the customer until everyone’s happy. I won’t mention his or his company’s name, but let’s just say that I really think that some day you will know who he is. (He owes me a Macbook Pro, incidentally.)
This guy’s company has the right idea. Incredibly capable, complex product. Let the customers benefit from it, but don’t let the customers get their greedy little hands on the product – they’d get lost and screw it up.
Like I said, I won’t say who he is or what this product does, but it’ll revolutionize its product space. This is the right way to infiltrate and conquer.
Now, frameworks can’t do this… end developers have to work with them. So now what?
I say the answer is to write every piece of documentation as if the people who are reading it really don’t understand it until the last few paragraphs or so. This will annoy writers to no end, it’ll be nearly impossible for coders to do, but this is going to be the tipping point. I dare say that the framework that caters to idiots will win, no matter how technically inferior (or demanding) that framework is.
If you can’t say it simply, either don’t do it or don’t say it until you can! And when you can, you’ll have the better mousetrap, and people WILL beat down your door.