I blogged some time ago about in-house Frameworks and how I regard them as “The Black Death“. This comes from years traveling the world troubleshooting and fixing ColdFusion and JRun applications.
Recently I have been working on two projects which were “supposedly” FuseBox frameworked. One was FuseBox 5 the other FuseBox 3. My opinion about Frameworks is if you use them do not fiddle with the core files and do not do things outside the Framework that should be done inside. If you are going to do either of these two things or even worse, both; do not use a Framework at all.
In one of these projects the application went to outer Mongolia and back before even getting to the Framework. In the other there were fbx_switch files with no switch-case blocks at all.
If anyone can convince me that there is good cause to use Frameworks and then usurp them; please let me know why?
DougHughes.net 
Comments on: "The Great Plague – UnFrameworked Frameworks" (6)
Mike,
I’d appreciate a clarification on your post. Certain frameworks provide mechanisms for overriding default behavior of framework components. Reactor, for example, allows developers to alter the behavior of generated DAO/Record/Gateway/etc by implementing custom methods in components that extend the base Reactor objects. While this is a supported feature, I can see where a beginner could get confused. Despite that, you’re not saying that this kind of thing should be avoided, are you?
Eric
LikeLike
Maybe I’m in the minority, but I’m of the “pick the right tool for the right job” mindset. I’m also a believer in the saying:
cheap. quick. well.
pick two.
As a contractor, I don’t always get to determine the requirements, or time lines (or technology stack) that I have to be responsible for. And as such, I sometimes need to make difficult decisions.
Case in point: a couple years ago I had to build a semi-working alpha build of a web app. It was giving to me at the last minute after the previous contractors kept failing to deliver what the client needed. This particular client was also still working off boot-strap cash, no VC funding had come in yet. Additionally, an important demo was already scheduled with a potential customer/investor.
So it needed to be “quick” and “cheap”. That doesn’t leave room for “well”.
At the time, I *thought* Mach-ii might be helpful, but I didn’t know enough about it to be sure. I played with it for a day, and got nowhere. But I *did* happen to have a handful of previously built UDF libraries that would solve part of the problem for me. And cobbled together with a quick, home-grown framework, we were able to deliver the demo on time.
Now…would it be just as “cheap” to use “mach-ii”? Well it’s open source, so sure!
Would Mach-ii have been able to build the same *type* of software package? Yes again!
But what if that didn’t turn out to be the case? What if I ate up 3 of my 8 weeks doing R&D on Mach-ii only to find out that (hypothetically) it didn’t meet our needs? Or that the OO constructs were too terse for my junior developer to figure out quickly? I’m now 40% into my schedule and have NOTHING that works…and a quickly moving deadline, and a lot at stake.
In those cases, I will often subscribe to “make it work NOW, and make it cool/elegant LATER”. Mach-ii (or any terse OO framework…I don’t mean to sound like I’m picking on the Mach-ii guys) would have been the wrong decision. In this case the “home grown” solution is what met our needs.
Your mileage may vary. 🙂
-nolan
LikeLike
@ Eric, thank you for your comment and I am not at all saying anything here about passing values or changes to a framework if there are mechanisms inherent in the design to allow that. Plug-ins would be an example in FuseBox for instance. I am talking about actively going in and modifying core files that are not meant to be modified. Or jumping in and out of the Framework mid request, for instance. I hope I explained that coherently.
LikeLike
@ Nolan, you raise a very relevant set of points here, thanks for the comment. What you faced goes right to the heart of another sad state of affairs. There are companies who are happy to spend well over a $1,000.00 and I do mean well-over on a single advertisement in a printed publication. Yet those same companies “penny-pinch” to the nth degree on spending on a web site that delivers value year in year out. It is bit like saying “print that Ad now and don’t worry about which paper, what ink and type style just do it!”
LikeLike
Mike,
I see very little reason to muck around in the core files unless you’re actively attempting to contribute to the project. I made a tweak to an earlier version of the FuseBox parser but that was only to increase the performance, not to alter the functionality (switching from CF concatenation to java.lang.stringBuffer to hold the parsed file), and I sent the change back to the FuseBox team for their consideration. It’s since been rolled in to the code-base.
Anyone who alters the core files for a framework takes on their own shoulders the responsibility for maintaining that code-base. It becomes a local branch off the official distribution, and isn’t supported officially in any way. The fact of the matter is that we’re in an industry that doesn’t generally enjoy a great deal of longevity in our jobs. Since there’s a very real possibility that I may have “moved on” by the time someone needs to maintain my code, it makes very little long-term business sense to allow a developer to bastardize the framework. It will only result in confusion for the next developer.
So, unless it’s an in-house rapid prototype that’ll never see the light of day in a production environment, leave the core files alone! And just think about how many intended “prototypes” ARE now the production systems!
My 2 cents worth…
-matt
LikeLike
@Matt, thanks very much for taking the time to comment, I appreciate that. One other insight I have, during my time with Allaire they launched Spectra and I became popular fairly fast and I think was the best CMS at the time. Spectra was built witha “middle-tier” of custom tags with a cfa_foo syntax if I recall correctly. There were two common problems we were often asked to assist with. One was Advanced Securiry based on an outdated version of Netegrity SiteMinder the other problem was caused by people trying to rewrite that middle-tier of custom tags. Your point about not wanting to leave behind something that is hard to understand is 100% spot-on, in my opinion. I have a feeling you probably aren’t without work very often ;o).
LikeLike