Why is it, that with every project I work on, I seem to run into yet another homegrown framework? Some mad scientist has decided he’s got a better way to process http requests than the fine folks who wrote Spring MVC or Struts. I’m not talking about servlet based frameworks that print HTML and were written ten years ago. Sure, it sucks to be on a project like that but you can’t really be that angry about it – those are the tools that were available back then so that’s just how people did stuff. I’m talking about the projects that started a year ago, yet still have some guy’s pet project MVC or data access framework.
I’m not sure why this seems to be such a common occurrence. Perhaps the culprits are those who’ve just finished reading their first patterns book and really feel the need to put together a nifty framework using all those patterns. While implementing a framework may be a useful academic exercise to become familiar with patterns, using such a framework in lieu of a proven solution that solves the same problem is probably not a great idea. Many of the patterns required for a web application have already been implemented in existing frameworks. In fact, identifying patterns in a framework such as Spring is also a good academic exercise.
While it’s very possible that you’ll need to extend an existing framework or write something that is domain specific, it’s not very realistic to think you’re going to single handedly write something like a data access framework that’s on par with an industry standard solution like Ibatis or Hibernate. Don’t get me wrong, it’s not like I think I’m going to be using the same set of standard tools five years from now. However as I've mentioned before, once a tool has made my list of preferred solutions it takes a quantum leap forward for me to trade it in for something new. In all fairness, maybe you’ve created a solution that is indeed a large enough advancement to justify replacing an industry standard technology. If you truly believe that to be the case, ask yourself how you’d feel about releasing your framework to the open source community. Chances are, your gut reaction will be that you don’t necessarily want engineers from around the world scrutinizing your code just yet. It’s easy to push your solution on a captive audience of co-workers. Things tend to change when the people evaluating your solution are a group of completely objective strangers.
It’s easy to become enamored with your masterpiece and convince yourself that it makes sense for your company. The reality is that teams of talented engineers have created the tools you’re trying to replace. An endeavor of that magnitude is a large project in its own right and would require your full attention. Most likely you’re not able to make that type of time commitment. Even if you were able to replicate their results you’d be creating a proprietary solution for a problem that’s already been solved using technology that’s familiar to developers everywhere. It’s very hard for me to envision a situation where the cost incurred to develop, maintain and document that proprietary solution would be worthwhile. Do yourself and the people who inherit your project a favor and take advantage the technology that’s available.
Posts
Well said Chad. Only caveat I'd throw in there is of course choosing the right tool for the job. I've seen plenty of the reverse where something excessively simple is needed ( and there is no forseable growth to indicate something vastly more will be needed ) and yet a huge framework is chosen because it exists - when the reality is just using the tools built-in to the language without a framework would suit the project just dandy and require no learning curve for anyone.
ReplyDelete-Mike
I'll tell you why: frameworks are reusable. In fact, frameworks are just about the only good way to achieve reusability in OO. Even if you choose the right tools (i.e. frameworks) for the job, there's always some customization that will happen naturally for your project, for the type of work required on a repeated basis. Send a lot of emails? A template system might evolve out of that. Do a lot of messaging? You'll probably want to build helper classes to do most of the dirty work, and so on.
ReplyDeleteI'm not countering your argument: frameworks are bad when they get mixed in with the ego of their makers, or there's too much unhealthy attachment. Especially when they start bothering the rest of us to use it, too (there's a big difference between innovation and Yet Another Framework). You need to be objective enough to realize when your "little customizations" start to approach the scale of 3rd party frameworks, and recognize when they do it better.
I'd say making frameworks is healthy and natural. What's hard is losing the attachment, and choosing the right tools.
Good point Tim, I probably should have qualified my rant more clearly. I’m definitely not trying to say frameworks in general are bad and like I said, I don't have a problem with something that was created before a standard solution was available. The inventions I'm talking about are ones that are meant to be used in lieu of a common, widely used framework that provides the same functionality. My favorite example of that is a homegrown MVC framework where I find myself digging through large servlet hierarchies and custom workflow for handling http requests. I certainly don’t have any problem with domain specific frameworks or customizing and adapting existing frameworks to solve business problems - that’s what we do. I just don't like working with a framework that was created last year because someone wanted to write a front controller. Thanks for the comment Tim, I certainly respect your opinion and hope you check in once and a while to keep me honest!
ReplyDeleteYes, I totally agree with you on this point. You see it every day on sites like The Server Side. I guess you could call it "framework spam"!
ReplyDelete