How Do You Decide Which Framework to Use?

GPolancic asks: "Software frameworks are increasingly popular software reuse technique, because they provide infrastructure functionalities to an application, or a layer of an application and therefore reduce the work of a software developer. Numerous complementary (for example: Struts and Hibernate) and competitive (for example: JSF vs. Struts or JSF vs. ASP.Net) software frameworks are available as both proprietary and open source software. A major precondition for the success of a software framework is their acceptance, which is related to market share or community size. On the other side, application developers need to review and select the best available software framework for their needs. Which factors do you evaluate before you decide to use a specific software framework?" "Our presumption is that software developers mostly evaluate following software framework characteristics based on:

1. perceived ease of use (e.g. easy to learn, easy to adapt)
2. perceived usability (e.g. improving developer performances, reducing work, faster development),
3. perceived sustainability (e.g. perceived long term support, supporting standards, clear project directions) and
4. perceived fit to specific developer requirements (e.g. suited language, suited functions, suited architecture).

What are your criteria? Do you support the factors listed above? I am not asking for a preference on a specific software framework, but rather an explanation on the non-trivial task of framework selection, which might be very usable for both frameworks developers and framework users."

Comments

Easy to decide...

[moronikos]

You use the one your boss tells you that you are going to use.

Difficult to answer

[IntelliAdmin]

This is almost as bad as asking "What programming language to use for a project" It all depends on the needs and experience of those involved. Sometimes it means rolling your own, other times it is better to get one that has been fully tested in the field for some time. Either way it is a silly question to ask.

Framework schmamework

[quantum bit]

I've played with a bunch of frameworks based on Java, Ruby, Python, etc... However for my last few projects I decided to go "old school". Since the target platform was Windows, that meant plain C and Win32 API. No MFC or anything. Staticly linked libpq if I need database access. Extra plus is that without C++ or COM frameworks, I can use mingw gcc on my BSD workstation to cross-compile.

It was a little more work up front, but I've gotten nothing but extremely positive responses about the interface. The application binary usually is under 50k, even the larger ones don't break the 100k barrier. They're extremely quick and responsive on modern machines, and still very usable on older ones. I like to do processing asynchronously (i.e. user types a few characters and a DB query kicks off in the background when they stop typing) and it keeps things snappy. It's pretty easy to literally run circles around all the bloated apps eating up tens of megs of memory or more.

I'm starting to sour on frameworks

[Jerf]

I've been developing for about ten years now; not as long as some people, but enough to be getting over the ten year hump for competency. As a result, I don't expect that everybody can pick this idea up and run with it, but it might color how you look at the frameworks.

I'm really starting to sour on frameworks. Libraries, love 'em to pieces. You want to take care of all the bit-bashing in the video card and present me an OpenGL interface, thank you very much. You want to give me a proper 21-st century file abstract like the KDE io-slaves, you have my gratitude. But you start bundling together five or six different technologies, each themselves fairly simple, and give me this unified framework or something, and in short order I'm likely to be cranky. This is especially true for things that are themselves fairly easy, like emitting HTML.

The problem is two-fold:

1. The resulting framework is quite often nearly impenetrable to an outsider, so when it's wrong, it's really, really wrong; even an open source framework might be of only dubious value since you're unlikely to be able to unravel all of the pieces in any useful amount of time.
2. As you add pieces together, the complexity of the whole increases geometrically. (Not "exponentially" as the term is commonly abused.) This can be mitigated by maturity, both of framework or core developer, but that's more rare than you might think. But the thing is, you are very unlikely to need all of the pieces. If the framework does 40 things, at a complexity of 1600, but you only need to use it for 12 things, at a complexity of 144, you're gaining an awful lot of complexity. (The numbers are of course made up, but the idea holds; don't try to over-rationalize the figures.) What's worse, as mentioned in the previous point, you might want to do 3 things that the framework fights you on, and now you're either going to have to give up on those 3 things, make unbelievably ugly hacks to get each of them half-sort-of working, or scale a huge learning curve to fix the framework that you are now significantly invested in, but know effectively nothing about the insides.

Especially in this age of using more dynamic languages, I'm finding I'm a lot happier taking smaller libraries and tying them together with my own frameworks, which I understand and can make sing and dance in exactly the ways I need them to with only the minimal complexity.

One important point here is the scale of development. If I'm going to do a three-week project, I'm going to probably go ahead and use a framework. But the larger the project, the larger the team, the more time that geometric price has to come up and bite you in the ass, where you Absolutely, Positively Need this thing the framework can't do, and it has to be done by tomorrow.

Also depends on your skill level, of course. And one of the cardinal Laws of Programming is that there are no Laws of Programming, only tradeoffs. I don't expect everyone to agree, I'm not pitching this so much as throwing it out as food for thought. Caveat, caveat, caveat.

I don't do Java, but my guess is that Hibernate, to the extent that it is a framework, is probably a win because it's so mature. But then again, you can also look at it as a really big library, because it sure does seem to play well with a lot of things. I think one of the distinguishing charateristics of a "framework" as I mean it in this post is that it is well-nigh impossible to glue two "frameworks" together, and sometimes even adding the capabilities of an additional library is an exercise in frustration. But the upshot is, I'm finding in practice that I'm a lot happier and more effective in the medium and long term, even on my own projects, with libraries that I tie together myself and not "frameworks".

While I'm not dogmatic about any particular one of them, the Agile-style development really help with this, and I might not feel this way without their influence. Automated Test (unit tests, usu