One of the most difficult things to learn about project management/development is the difference between adaptability and "does the work for you". People who have not worked with the latter might have a tendency to desire the latter (after all, who does not want less work?), but my experience has been that these types of systems always end up extracting their "pound of flesh". There Ain't No Such Thing As A Free Lunch.
The first time I used Struts, I was enamored of it for about a day. Then I realized what a pain it was to work with. It has been a while since I've used it, but my memory is primarily one of, "What magic incantation do I need to stuff in some random configuration file to actually make this page transition work?"
Another example, Ruby on Rails: I always thought this name apropos. You need to jump off and do some 4-wheeling? No dice, dude! You're on Rails!
How about this description of Cocoon:
Apache Cocoon is a web development framework built around the concepts of separation of concerns and component-based web development. Cocoon implements these concepts around the notion of 'component pipelines', each component on the pipeline specializing on a particular operation. This makes it possible to use a Lego(tm)-like approach in building web solutions, hooking together components into pipelines without any required programming. (emphasis mine)
Hint: anyone who suggests that you can program without programming is suffering from a logical fallacy. The Cocoon folks avoid this by offering that you can "hook together components into pipelines" without programming. How pipelines become applications, that I'm curious about.
I don't mean to pick on specific projects, but I'm just pointing out examples. There are certain advantages to having components, but the end goal should be adaptability and maintainability. Not the mess of an MBean talking to an EJB Session Bean that was looked up over JNDI that talks to a JMX Component that I have seen one too many times. ("See, we've got this framework, but it won't talk to this other framework, so now we're writing a Facade class (ooh! Design Patterns! It must be good!) to expose things to the other framework...")
For whatever reason, this appears to be largely a Java phenomenon. There are more Java frameworks than there are applications built on them!
...well over half of the time you spend working on a project (on the order of 70 percent) is spent thinking, and no tool, no matter how advanced, can think for you. Consequently, even if a tool did everything except the thinking for you -- if it wrote 100 percent of the code, wrote 100 percent of the documentation, did 100 percent of the testing, burned the CD-ROMs, put them in boxes, and mailed them to your customers -- the best you could hope for would be a 30 percent improvement in productivity. In order to do better than that, you have to change the way you think.
Fred Brooks [paraphrased] as quoted from Allen Holub's http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html
The main thing that a framework needs to do is stay out of your way. It should not be an impediment to future progress. You should be able to say, "I want to change the sorting algorithm for this list," and be able to accomplish it quickly without the framework getting in the way.
I'm not suggesting that you should go through "Not Invented Here" syndrome, and re-implement wheels, airbags, windshields and turn signals, but that understanding the balance between adaptability and the enforced consistency of a framework. After all:
A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.
Ralph Waldo Emerson
No comments:
Post a Comment