Do unfamiliar frameworks make you nervous?

Question

Our company is a small (non-technical) startup who is currently going through a developer transition, and we considered bringing in a local web development firm to work with us on a project basis.

I sat down with a developer from one of these firms, and gave him a tour of our code base. He seemed like a pretty bright guy, and while he admitted no experience with our particular PHP framework (rhymes with 'Bend'), he appeared to be a totally capable developer. We found out the next day that they didn't want to work with us because of our choice of framework.

For people who do consulting or work for development, how much does a client's choice of framework influence your decision for taking the client? Obviously, language and platform make a huge difference (I wouldn't expect a PHP shop to write C#), but as a developer I would always pick the client using any framework, over one that does not.

I know everyone has their own comfort level and areas where they specialize, but do you feel comfortable tackling a new technology armed with only some API docs and google? Do you try to make this as clear as possible to the client? What are some reasons you would turn down someone for their choice of framework (assuming it fell into your basic realm of knowledge)? And with all the frameworks out there, how is one developer ever expected to pick something others can support?

Answer 1

Absolutely.

There are so many poor frameworks out there, and this may be more true in PHP than any other language. There are several PHP frameworks, even popular ones, which I would not take a job if the client insisted on using. One rhymes with "Zrupal".

If a consultant has problems with a framework or is unfamiliar with it, it will affect their ability to provide accurate estimates, and may also affect their ability to deliver the quality they are used to.

A framework is like any other technology choice - you may reduce the number of resources available to help you, either by preference or lack of knowledge.

Answer 2

I would venture to say that anything that is unfamiliar will initially make you nervous. This is especially true in frameworks. While yes, 'PHP is PHP after all', I'd be most nervous about undiscovered gotchas and caveats.

I would not take on a project if I didn't feel confident that I could deliver in an agreeable amount of time. I want deliverables to be solid, as bug free as I can get them and as defensively written as possible. It is hard to code defensively when you don't know what to watch out for. I wouldn't stake my reputation on an unfamiliar framework.

However, it's not like there is a shortage of brilliant people who use your framework of choice, or any other. I think the developer who turned you down was being extremely honest and professional. They simply did not want to produce something that might be of diminished quality.

I agree with you, in many cases any framework is better than no framework, the same could be said about version control software. Many people argue that while VSS is a horrid, wretched beast, it beats not having anything at all. Still, I would not work on a project that used it if I had a choice in the matter.

If we assume that the company had lots of opportunities to work on projects where they knew that they could deliver effectively, it's only natural to decline a project that they saw as 'scary'.

Answer 3

It depends.

On a purely technical level, I certainly have no problem bouncing between frameworks or even languages: I have a pretty broad background, and thanks to it I've got the high level skills (understanding algorithms, language design, etc) that make those kinds of switches relatively painless.

However, this sort of thing is rarely a purely technical concern. For example:

• I will avoid projects that are complicated by poor management (one facet of which may be choice of a bad tool or the wrong tool for the particular job).

• I can make more money right now marketing myself and my company as a source of expert-level Drupal services, an expertise I maintain by using Drupal and participating in the community. Unless the economic winds change, I am not likely to sign onto a nontrivial non-Drupal project, because taking a several-month break would impair my ability to maintain this high level of expertise.

Answer 4

Unless the framework is historically know to be a hindrance to development effort, it seems childish to turn down a gig over the framework. You could also attribute it to personal insecurities.

In my case, when working with a new framework I am more likely to be annoyed that it does not behave with accordance to my mental model. Of course within a few days I'll eventually see the internal thought process (Or lack of though process...) that went into the design of the API and make a final decision on the framework.

At the end of the day your team will have to compromise though because it is impossible to make everyone happy. Unless you have a team of clones which in itself will kill the productivity due to the lack of insight which normally comes from a diverse team of developers.

Answer 5

One of my clients has an important coding investment on a framework that is no longer mainstream. There are two problems with that:

1. The framework doesn't keep up in implementation or bindings to new mainstream technology, and that makes maintenance comparatively costly (open-source has changed the way we develop software, and there's a lot of open-source for mainstream environments/frameworks, and very little for the rest).
2. It is difficult and very expensive to find developers to work on the code base.

My take on the second point (the one that concerns your question) is that developers will consider the time spent on non-mainstream a handicap towards their future employability, unless they are paid an amount that allows them compensate with study and experimentation should the proposed job come to an end (work six months on some open source project with bleeding-edge technologies).

I myself spent several years consulting on architectures based on Java technologies. Had I continued to stay away from what's going on on the Web2, gadgets, convergence, etc., ecosystem, I would have become employable only by large corporations to work on their legacy stuff. That's too high a risk.

Nervousness? I don't think so. I could probably name off-memory a couple dozen mainstream frameworks that are important, of which I can say I know only a handful. Having to learn a new framework for a new project is common enough to be normal.

Answer 6

If having to work with code you don't fully understand doesn't make you at least cautious, that's a bad sign.

But armed with the source code and the API docs you should feel confident enough to start working with it, albeit at a slower pace than you'd normally do.

On the other hand, if I knew a framework was rubbish, I might think twice before taking the job.

Answer 7

No.

So long as I can grasp what the cost will be to working in that framework and explain that cost to the customer. I'm fine taking on the challenge and getting to learn something new.

However, I will pass up on frameworks is they are frustrating to work with (I mean more than regular).

Answer 8

Did he give any reasons as to why he did not want to work with the framework? Really, I don't think it's good to be afraid of new technologies and frameworks, though it's OK to admit to being nervous and admit there may be a learning curve and some extra time required while catching up with the new framework. It's OK to reject a project if the timeline doesn't permit learning the new tech/framework. But to reject it just because it's new and different? I don't think so.

Answer 9

1. All all-purpose-frameworks make me nervous. The reason is, that at some point, you'll hit a wall, because your actual app doesn't neet to perform all task sufficiently well, but to perform its core functionality in an excellent manner.

2. There's a number of common problems all-purpose-frameworks have to some extent.

   • No clear distinction between the component library they come with, and the actual framework. That framework of yours, that rhymes with 'Bend', provides a lot of components. The framework part is actually quite thin.
   • They tend to be bloated and slow. While the better ones give you an enormous amount of comfort features out of the box, this comes at quite a cost.
   • They impose an incredible lot of concepts, some of which are arguably just a matter of taste.

In the end, there's a lot of reasons to dislike all-purpose-frameworks in general. And for every single all-purpose-frameworks there a lot of concrete reasons.
And if you have found a framework, that you're really comfortable with, it is very hard to switch to another. It causes a loss in productivity and probably a lot of frustration.

Personally, I think the concrete framework may even be the issue, because working with it feels like working with a Java framework and if I wanted to work with Java, I'd work with Java.
There's a number of PHP frameworks that gained popularity without being marketed by the Zend Group.

edit: Here's an interesing talk by Cal Henderson which (among other things) deals with problems many frameworks have.