The dark side of frameworks

Some time ago I had a somehow bad experience with a (good) company that I’ve applied to. This is the email conversation with them:

Dear Constantin,

thank you again for your application.

I am sorry to inform you that, despite your interesting CV, your profile does not fully match the requirements for the vacant position.

We truly appreciate your interest in XYZ and we wish you every success for your future career.

Best regards,

XYZ

Then, being just curious, I replied to them:

Hello,

Thanks for the reply but could you please tell me what the mismatch was because I really do like your company and I would really want to work for you.
Thanks again!

They responded:

Dear Constantin,

our Lead Engineer could not find any Symfony experience in your CV which is why he decided to proceed with other candidates.
I hope this helps!
Best regards

But this does not seem right. It looks like they have become dependent on a particular framework so hard that they could not hire many possible good programmers because they lack the experience with a particular (and simple) PHP framework. The DDD in me started to scream so I wrote this to them:

Thank you very much for your time. I have a message to your team lead:

Symfony is a framework like any other. It is very well documented, there are lots of tutorials out there that can get an passionate developer up&running in days. I used Zend framework for Web application as starter but I could replace it with any other framework at almost any time. Any developer can write code that works for just a particular framework but only the best developers write code that are framework agnostic. After years of programming I realized that frameworks are implementation details, they are just noise that draw developers attention from what really matters: the domain! Of corse,  they should be used, we should not reinvent the wheel, but they should be replaceable at any moment without full rewrite.
This comment is specially about general purpose frameworks like Symfony and Zend. They are not Magento. You afford to become dependent to Magento because it offers you all there is about for a six digits ecommerce shop. But general purpose frameworks are just a collection of libraries. You should protect yourself from them. You should not step into framework creator’s trap. If you do you will not be able to hire good programmers because they do not have experience with it.
DDD has help me to separate my pure core domain code from the infrastructure/technology. This is good because technology changes faster than the business. If you do not separate them then you will loose money just to rewrite your code to match the latest, fastest, most secure version of their framework.
What has Symfony and the other framework don’t? PSR-7 Controllers? PSR-11 Dependency injection container? PSR-3 Logger? These are present in any PHP framework. An ORM? No, it is from Doctrine.
About code quality, what does teaches Symfony on its documentation page [1] ? It tells the programmer to use the service-locator anti-pattern in the controllers by making the DIC available as $this->container. What the lazy programmers do then? They use it and thus they make their code less testable, depending on hidden services that only the author will remember.
If you are indeed so dependent to Symfony that you will never change it then probably we won’t match.
Thanks again for your time.
Being, like I said, a good company, they have responded with this:

Hi Constantin,

thank you very much for your effort to write down your thoughts.
You have a point there!
I’ll pass this on.
All the best for now
 My question is this: it’s pretty straight-forward how to help the company that you work for to understand what code quality means: you write clean code that works and they feel the benefits but how to help the companies that you do not yet work for?
It seems that frameworks can be evil in ways that are not easy to spot.
What do you think?
Disclaimer: I don’t consider myself the best programmer in the world. That’s not the idea. The point is that they  didn’t even consider to test my abilities. I was disqualified from the start. I may have been Martin Fowler, Uncle Bob, Eric Evans, Vaughn Vernon  or Greg Young (and many other!), it would have not mattered to them because I did not know Symfony.
To be continued.
The dark side of frameworks

6 thoughts on “The dark side of frameworks

  1. Alberto says:

    I totally agree with you. I have had similar experiences, because a lot of times I read works offers with sentence “Programming experience in symfony”. WTF? In symfony? Is it a new language?

    Then you know developers that works with symfony as a new language, and you find containers in the whole application because the domain is not separated from the framework, you find objects that are not services in the container, and this people doesn’t understand that services are singletons (I found bugs because of this).

    I have started working with symfony a few months ago in a new version (that started 2 years ago without me) of our application, and I have migrated a module that I did for the old version that was build with codeigneiter framework. I only have changed some queries and I have created a very small controller in the new bundle. It was enough. It is working because it was portable from one framework to another. But now I’m trying to do changes in other parts of the application (it is very young legacy code) and it is horrible, people with a lot of experience in symfony (not like me) is using the framework like a new language, and it is impossible to create automated tests, the domain is totally coupled with the framework.

    And in some interviews I have listened the same: “we are looking for experts in synfony, but you don’t have enough experience”. I have worked with 3 different frameworks in PHP, but I don’t have years of experience in symfony. It is a pity.

    1. Next time they say this to me during a face2face interview I will ask for a laptop and begin to write an entire Symfony replacement framework, including unittests, without specific infrastructure adapters. I will not finish it, of course, but the look on their face == priceless 🙂

  2. To be honest, I think you were lucky you weren’t hired..
    If I were on your feet I would be first frustated: I have been rejected!
    But then I would be really happy: I don’t won’t to be working in a place where they hire developers based in the experience with frameworks.. First, probably your ideas of what constitues a good architecture are totally diferent from the team. Second, I don’t think they are going to hire good developers based in that criteria, so you don’t want to work in a place where there are no good developers.

    I think it is better you have been rejected now, that being hired and being constantly frustated.

    (Obvisouly I am missing the whole context of the company and the interview and I am generalising a bit..)

    1. That is the natural response from anyone. The interview does not exists past a fast rejection. It was like this: I applied online, they view my CV then rejected my application. I would have understood if I miss other skills, like “experience with 1 billion/requests_per_second web application” but not experience with a general purpose framework but they didn’t even bother to check my skills. That is, that framework is so important that is mandatory.

  3. CholTiopic says:

    Symfony container is not a service locator but a dependency injection container, the later being not against SRP. Differences between these two patterns are well covered all over net.

    1. I know exactly what is the difference but the DIC should be used like that only in the composition root. Clients should not resolve their own dependencies, it would not be “injecting” anymore.

Leave a Reply

Your email address will not be published. Required fields are marked *