Questions to ask yourself before you write your own framework
I made a comment, but it turned into a posting, so here are some questions to ask yourself before writing your own framework (as opposed to using M2/MG/FB/CB/etc.).
There are are a number of reasons NOT to use a community framework. A general framework simply can't be the optimal solution to every use case. However, you need to think very carefully before writing your own framework for a production application. It is not a trivial choice and is akin to deciding to build rather than buy your next home. It isn't wrong (for everyone), but it isn't a trivial choice.
The questions I would ask someone thinking of writing their own framework . . .
1. Can you write a better specific solution than the "community" generalized solution? The vast majority of developers just don't have the skills required to do this successfully even though they are focusing on a more specific problem set.
2. Are you sure you fully understand your problem domain? It is possible that the community framework has flexibility you don't require for your use case. It is more likely that it simply has flexibility that you don't realize you will require because you have less experience in architecting applications than the sum of all of the community developers who have helped to shape the framework.
3. Do you understand exactly how the current frameworks work, why they work and which patterns you can safely remove (along with which patterns you might want to add)? To create your own framework without at least playing with and pulling apart current community frameworks is the height of folly. You may not need everything the community frameworks do and some of their generalized patterns may not be optimal for your problem space, but you can't even start to write a better framework for your use case unless you've ripped apart the code base for the community frameworks and really understand exactly what they do and why you would choose to do things differently.
4. Is it worth the time? It takes a LOT of time to write a solid framework (probably about ten to fifty times as long as you expect). And then you need to create documentation that is at least as comprehensive as that for the community projects. Wouldn't you be better using that development time to leverage existing community assets? Perhaps you could extend the community frameworks for your own use or even submit code for possible inclusion into the frameworks themselves.
5. Is it worth the learning curve? Not only you, but everyone else who has to work with the framework is going to have to learn your framework whereas many of them may already be familiar with MG or M2. Every time you hire a new contractor or developer you're going to have to teach them your framework. Is it really worth it?!
There are LOTS of reasons to use a community framework, but there is absolutely nothing wrong with writing your own (every application uses a framework - the only questions are whether they wrote it or leveraged an existing one and whether it is a good one or a hacky one). As always - it depends.
ColdFuion gets a lot of grief compared to other languages because there is a LOT of bad CF code out there. Custom frameworks get a lot of grief because most custom frameworks are not very good. That does not mean there is never a reason to write your own framework. if that was true, Model Glue and Mach-II wouldn't exist - we'd all still be using Fusebox as the teams behind MG and M2 "broke the rule" and wrote their own framework, so it clearly isn't always the wrong thing to do.
But remember, writing Model Glue or Mach-II is kind of like creating Amazon.com - it is way harder than you'd expect. The vast majority of e-commerce start-ups will not become Amazon, and the vast majority of custom frameworks will not become M2, MG or Fusebox level popular.
One other comment. There is NOTHING wrong with writing your own framework as a learning exercise. In fact, for anyone who has the time, I don't think anything could make you a better programmer than creating a framework (or set of frameworks) to replace MG, ColdSpring, Reactor and the various other community tools out there. I don't know that you could justify it on company time, but as a learning exercise it is a great way to really understand what you are doing.
So, without getting into the usual silly flame wars, does anyone else have any other specific heuristics they have used when deciding whether or not to use a community framework for a specific use case?





As for the question, "to framework, or not to framework" my choices so far have been rather simplistic. Building your own takes a lot of time and I think the majority of developers understand that. For that reason alone you are not going to get many managers on employers time(and money) sanction it, which means building one on your time - this is usually out of the question. Most of my other sites have used community frameworks as I start the initial builds and then developers join in on the projects and support my work. Having a pre-documented framework, with mailing lists for problems when im away is invaluable! As for not using a framework, its usually because the site is small 4-5 pages or under with simple DB interaction. Anyone with basic CF knowlededge could rip through the code in 30-60 minutes and understand how it is all pieced together.
Thanks for the catch. It was a slip rather than typo as I'd been thinking about Mr. cf.objective()! Sorry about that :-<
Maybe the community framework is the "middle way". For very small projects it may not ALWAYS make sense to use a community framework (although there is something to be said for the consistency of just always using one) and for extremely large projects, the high cost of creating and documenting a custom framework might be justifiable if it is a substantially better fit to a special use case than the community offerings.
Now, I am not saying that everyone should go out and build their own frameworks. Most (including myself) don't have the skill.... but by using only community frameworks and never trying to roll your own, I think to some degree, you hurt how much you can ever learn.
If you stand back and look at what is going on in the web development community, we have a ton of pre-fab applications and libraries being used. BlogCFC, JQuery, Prototype, Dojo, FuseBox, MG, Mach-ii (just to name a very few)... and then on top of that we have programs that help us greatly with insight menus, auto generated code, and "design views".
While all of these things a great, my fear is that we are becoming a community of people who know how to "USE" things rather than "BUILD" things. Now, you might say that that makes us better, faster programmers... why re-invent the wheel right? Well, what happens when you use someone else's wheel and it stops working for no apparent reason? Most of us are dead in the water. I see this all the time. People (even those that I have worked with directly) are so used to working with pre-fab libraries and apps that when something doesn't work they don't even know how to go about debugging.... they have lost the ability to understand how it works, and only know that is *should* work and that it is not currently working.
Just to sumize, I am not saying the community frame works are bad, they are there for a reason - they work. I just fear that some people (especially those who are perhaps not motivated to really get into the nitty gritty) might program themselves right out of knowing how to program. [ ... end rant ... ]
I happen to agree with you 100%, so let me take the opposite position (:->). The opposing argument is that most of us don't know how to write an operating system, how to design a VLSI chip, how to build a memory chip, how to architect a system bus, how to write a compiler or language or how to write our own garbage collector (unless we programmed in C++!). Doesn't mean we can't take advantage of those tools to achieve our outcomes.
I do think an in language framework is a little different, however, and I've got to say that I agree (a) you learn more by writing your own (whether or not you end up using it in production) and (b) if you don't know exactly how a framework operates, you are introducing a dependency that can get you into trouble if you have a problem at 3am and the lists are quiet or if you're trying to do something most people don't know how to do with the framework (unlikely, but it happens).
Right, exactly. I don't want to take it to the extreme; I mean, I drive a car without knowing how to build a car... but on the same note, I accept that fact that if my car breaks down on the side of the road, I'm waiting for AAA to arrive (I'm not one of those guys who knows how to change a tire... I live in a city). I just want to point out that not learning how to do build something can limit what you can do with it.
I think a lot of people responding to this take the crappy code for granted. You can learn a lot from crappy code, too. Take new developers for example, do you think they'd understand object-relational mapping and model view controller frameworks before they knew how to write a SQL query or get data into coldfusion? Not likely if coldfusion is their first language, but if they build their way up through the crappy code, learning how to manually query the database, build list views, search, run into some problems along the way, etc, they'll be far more likely to understand why those frameworks exist in the fist place! Another argument for crappy code is to teach the people who create the languages about the kind of mistakes people make, walls they run into, etc, which helps the base language mature.
That said, I think anyone with any kind of project they want to release should ignore any argument against it and RELEASE IT! If an individual doesn't like their project, they can just as well ignore it.
Writing your own code is good because:
- You learn the problems, come up with solutions, and develop a better understanding for the solutions other people have come up with.
- You can help the community by taking another approach to the same problem, whether better or worse, it's another idea in the pot.
- By writing my own code, I can directly connect pieces that use similar functionality, and reuse the code more effectively. If I were to go out and grab the best calendar control, best datagrid, best tab control, best dropdown menu, best presentation layer framework, etc, and then slap them into my project, chances are not many of those pieces are going to work off of each other. By developing my own controls, solving my own problems, I can come up with a way for those pieces to share a large portion of their javascript, css, imagery, etc, which makes for an elegant solution. This may not be the best example, but I think it illustrates the point pretty well.
- We need to solve our own problems before we can begin to solve someone else's.
Tim
Just be ready for the flames though . . . I got quite a bit of negative feedback for releasing LightWire even though to me it has a very clear and distinct position!