To Framework, or Not To Framework? It depends!

I just responded to a post over on Alagad.com about using "homegrown" frameworks vs. using "regular" frameworks, and my comment quickly became a catalyst for a blog post of my own on that same topic.

Frameworks are a pretty common holy war these days. The phrases "always use frameworks!", and "which framework is best?" are both seen pretty regularly on blogs, message boards, or overheard at various user group meetings.

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.

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.

Case in point: a couple years ago I had to build a semi-working alpha build of a web app. It was given 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* 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.

...and what's rule #1 about being a contractor? "NEVER miss your deadline!"

In those cases, I will often subscribe to the "make it work NOW, and make it cool/elegant LATER" philosophy. Mach-ii (or any OO framework really...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.

I've used some homegrown frameworks that weren't saving me anything (one in particular was developed by a previous engineer and nobody ever thought to replace it) but also weren't getting in my way too much, so it was a non-issue; and I've used some that were basically "Fusebox lite" and didn't provide much more than a naming convention for the CFM files (which can be extremely helpful by itself -- don't get me started on how anal i am about naming conventions! *grin*). Each item has it's place. As do the "standard" frameworks that we hear much more about -- Model Glue, Mach-ii, Fusebox, etc.

Just for the sake of argument, and to give a few more examples, currently in my queue are the following projects:

1. I'm working on a C++ app. The technology stack (C++, Visual Studio 2008, g++, Boost, and some homegrown libraries from the other developer) was already in place, and is non-negotiable. So in this case, I had no choice in the tool set. Now that I've been on the project for a while, I can see that adding a framework (or changing to Java as I had originally waned to do for this project) won't save us anything anyway. Unfortunately I'm under NDA, so you'll just have to trust me on this one. :)
2. A web app I'm working on is more 'open', technology-wise. The client has specific features he'd like to see, but he couldn't care less about what the technology stack looks like. In fact, he'll never even ASK what tools I'm using. Additionally, the deadline is much more flexible here; so I'm using Model Glue Unity for the front end, and either Model-Glue Flex for the back end, or some home-grown Flex code coupled with a handful of CFC files (most of which I think can be auto-generated via other tools). Model Glue will save me some work (even while just prototyping, MG proved very helpful in this regard), and will provide a nice separation of the layers, allowing me to concentrate on one thing at a time, and split up the work easily...which happens to match the work flow on this project extremely well.
3. I just launched a site for my recording studio. Currently, it's basically a static brochure. No moving parts, no database connectivity. Thus, there's no need for a framework (homegrown or otherwise). The entire thing is a handful of CFincludes for the header/footer and not much else. In this case, any sort of framework would be overkill.

Your mileage may vary. :)

-nolan