Frameworks sound great until you inherit a franken-app built using one. You might be able to understand bits if they religiously followed the dogmatic usage of the framework but more likely they just wanted to get stuff built and not wanting to learn someone else's idea of the perfect wheel maker framework and so ended up still building something unique, baroque, and possibly impenetrable.
Frameworks in the most case feel like straightjackets, so I understand why developers feel the need to abandon some of the magic and build bits that are actually simple robust and supportable, but it can become hell for subsequent developers.
I thought that OWL (at least the Pascal version) was pretty reasonable for what it did.
I can understand the frustration with Java, though. The first time I started reading through "web.xml", I thought it was a bit much. Then I read the EJB specs...
Struts, at least the older versions I've had to maintain, is a nightmare. RoR seemed to have a lot less BS to do the same thing.
Using the right framework for the right reason is a productivity boost.
I agree. The difficulty with this is in the long term. Things change: new opportunities, new technologies, new developers, new functionality. Even if you were 100% certain of your choice on day one, it's difficult to measure the precise point beyond which your framework is no longer the "right" framework. I'm interested in solutions to this problem.
but doesn't this happen anyway? Business requirements change, technologies change, the tool that you chose 5 years ago is probably not the best tool for the job today, regardless of whether it's a framework, a library or another piece of software in your stack.
A possible solution is to keep your business logic framework agnostic, and write thin wrappers to plug into the framework where required. In theory it should be possible to change frameworks without incurring a major rewrite. This is easier said than done of course.
I like your post. I agree with the fact that a framework does restrict your control and creativity. However, what you get in place of that is standardization.
So if you have 10 people working on a project you don't want them all to be doing their own thing. You want a very standardized code base that is easy to understand by everyone. Easier to maintain, change, and, upgrade.
Frameworks in the most case feel like straightjackets, so I understand why developers feel the need to abandon some of the magic and build bits that are actually simple robust and supportable, but it can become hell for subsequent developers.