Unnecessary contrapositions in the new "Symfony Best Practices"

Posted on by Matthias Noback

Of course I'm going to write something about the new Symfony Best Practices book that was written by Fabien Potencier, Ryan Weaver and Javier Eguiluz. It got a lot of negative responses, at least in my Twitter feed, and I think it's a good idea to read Richard Miller's post for some suggestions on how to deal with an "early preview release" like this and how we can be a bit more positive about it.

Staying positive

One of the most important things we have to keep in mind: you don't have to agree with everything in this document. There are so many different ideas about "how to do things best", it would have been impossible to write a set of best practices everyone agrees upon.

As you can imagine (if you read my blog posts or have seen my presentations), I myself don't think many of the practices in the book could be described as "best". But then again, what is "best", and what is the type of project and/or team you have in mind when you decide that they are "best"? So, I really don't care about the document in this way. What the Symfony team thinks is best, they are allowed to label as "best".


But, and this is one huge "but": the way they introduced this book was very unfortunate (emphasis mine):

[...] community resources - like blog posts or presentations - have created an unofficial set of recommendations for developing Symfony applications. Unfortunately, a lot of these recommendations are in fact wrong.

To say such a thing in an official text is such a bad move, I don't understand why none of the reviewers has been able to convince the authors to remove this particular paragraph. Still, it is apparently such an important phrase, that not only is it part of the book itself, it is also being quoted in the article that first introduced the book.

You know, I have invested countless hours into working with Symfony, finding out how some parts of it work, writing about it (the Security Component documentation, Cookbook articles, 90 blog posts), talking about it in public, preaching Symfony to my team members and employers, finding new and better ways to do things with Symfony, and so on and so on.

Now I have always known that what I think is good, probably is not what Fabien thinks is good. But still, to actually read this in a public, official document - "a lot of these recommendations are in fact wrong" - well, that is just something that's very hard to process.

It is totally not necessary to write such a thing. It is a very mean thing to say to a community at large. It makes the authors look like old-fashioned managers, walking by the desks of their personnel, saying "you're wasting your time there, buddy", "you know, traditionally, Symfony developers used to do that, but we know better now" and "you are over-complicating things, get out!"

Let's not get all emotional

I totally agree with Richard Miller as he correctly states:

However, I do see no reason not to remove some of the more emotional and inflammatory language as soon as possible.

And, yes, I have to admit, I just used a bit of emotional and inflammatory language myself. But this article is not an official recommendation. It is a personal, opinionated blog post, so I feel totally entitled to do so.


To me the introductory paragraph and several other parts of the text communicate the message that "you're doing it wrong". It didn't have to be that way! It could have just been like, "you know, we think, this is the right way". So my first recommendation to the authors would be: change the text to reflect this community-friendly attitude. Even if the motivation to write the book was the "wrongness" of the approaches suggested by community authors like me, you should definitely hide that motivation, since it doesn't do any good to your relation with the community.

In general, there is no need for a best practices book like this to be opposed to anything really. It's not necessary to point out "mistakes" made be community people. And it only causes negative feelings in the reader's mind if they have to read about "things Symfony developers traditionally do", while they actually do those things, and don't know what would be "wrong" about that. Finally, it makes no sense to label a common approach as "overcomplicating things" or "over-kill". So just provide a list of the best practices and don't mention all the things you find a bad practice.

Good luck

I am a Symfony developer

At the end of this post, you may still call me a Symfony developer. I really hope the authors of this book will take my complaints seriously. Then I think that this book will have a long and prosper future and will serve as a good book for people to get started with the Symfony framework. When you've finished it, I recommend you to read my own book, A Year With Symfony, to get some more advanced insights into Symfony and how to work with it. Afterwards, I hope you will practice your coupling radar, learn to recognize the touching points between your code and the framework of your choice, and to actually break free from it, because:

It's not your code that needs the framework, it's you. And you need a good one. So choose Symfony.

PHP Symfony2 community
This website uses MailComments: you can send your comments to this post by email. Read more about MailComments, including suggestions for writing your comments (in HTML or Markdown).
Bolla Sandor

To be correct I never really cared about the language of the subject. I was just interested in how Symfony was thought to be used. For me the part about Forms was a bit of oversimplified but that's probably just because we use it in a more advanced way.

I would be really interested in a Community Best Practices discussion as well. Much like the PHP.net entries have as comments below explanation.

Sebastiaan Stok

> But then again, what is "best"

To me best is: The solution with the least amount of concessions.


then the "best" they describe is at least worst since there are a lot of concessions

mickaël andrieu

Hmmm, the main problem for this book is that is was not discussed with the community.

I don't like the idea that SL stay what are the ** Symfony best practices **.

The good way to do it should be to make a PR on symfony docs and let the community discuss and valid practices to apply.

For now, this is mainly Fabien's way to do apps.

I was so disappointed too to read "if you don't do like us, you are wrong". I trust Javier to improve it and make this contribution more "community-friendly"

Javier Eguiluz

Mickaël, regarding this phrase:

"For now, this is mainly Fabien's way to do apps."

That's precisely the idea! In other words, Fabien thought that it would be useful to publish a document outlining his own ideas about how to develop Symfony apps.

The intention of the document is not this one: "I'm Fabien, I'm smarter than all of you and this is the only good way to develop Symfony apps".

The intention is this one: "I'm Fabien and when I created Symfony2, I thought about how to use it to develop web applications. Unfortunately, what I see today doesn't resemble that. That's why I'm publishing this list with my own ideas. They are not perfect, they may not be the best ones, but they are my own ideas. If you want to follow them, that's fine. If you don't want to follow them (for any reason) that's perfectly fine too".

What you ask about the "Community Best-Practices" is totally different from this "Official Best Practices". The community of course (or a small group of people from it) can publish their own best practices. In fact, it would be great to have more than one list of best practices. We all would learn more that way.

Sebastiaan Stok

"In fact, it would be great to have more than one list of best practices".

But then you would need a list of which of the best practices guides, are the best practices. The "best practices" practices list, inception!

Why not 'recommended practices'? :)


i think for that he would have had easily created a blog post on his blog, it would have been even more along the lines that he has been doing.

mickaël andrieu

Ok, I'm not sure the word "official" was good for this initiative but I understand Fabien, I remember how hard he try to make SL developpers more "pragmatics" and his point of view is (very) important for the community.

The red line (imo) should be to implement this guidelines "as it" in SL insight as "Symfony practices are not respected": to be accepted, this rules need to be discussed and approved.

I'm +1 for an Community best practices :)

Matthias Noback

Well described, Javier, thanks.

Javier Eguiluz

Matthias, thanks for publishing this article and for sharing your thoughts on the best practices initiative.

Regarding the phrase that you mentioned ("they are wrong"), that's a very unfortunate phrase that has been updated both in the blog post announcing the best practices and in the latest version of the book to be published soon. There is nothing more to say about this: that phrase was totally wrong and it must be reworded. And that's what's happened.

And I'd like to make another comment with unfortunately I've made like a hundred times by now: in English "best practice" is a noun, not an adjective + a noun. They are not the "best" way to do things, they are the "official" way to do things, and therefore, they are named the "official best practices".

Matthias Noback

Hi Javier, thanks for your comment! Very nice to see that it has been changed. And sorry to bring the meaning of "best" up again then ;) I still think that to many people it at least sounds like you mean that the practices are "best" (in the adjective sense). So yes, that may need a bit more explanation, or a different title, like some people suggested before. Maybe something like "Recommandations for building Symfony applications - as approved by the Symfony team" (too long, I know ;)). Anyway, thanks again, also for making this important effort.


Yes, we removed this text yesterday I wish the PDF had been updated before you posted this ;). It was a mistake. We need strong language behind the recommendations, which I think we'll all like even more as we move and evolve it together. But, to say that anyone else is "wrong" was just silly. In fact, the more and more you learn Symfony, the more and more you'll find which things work for you and which things you want to do totally different. You are a perfect example of that, and it's also what makes Symfony great.

I hope I see you in Madrid!


Jorge Betancourt

I think you hit a key point: "the more and more you learn Symfony, the more and more you'll find which things work for you and which things you want to do totally different" As I've said before this new guide reduce the friction between new comers to Symfony and the framework, because when you start digging into Symfony you see a lot of recommendations from advanced users like Matthias itself that will do you write better code, but that are also "hard" to understand the why and the how in some cases.

So this new book is a wonderful way to start your journey with Symfony without getting into much problems. One key aspect I think is that you'll need to trust in the framework and it endless capabilities that will allow you to evolve your code into a more sophisticated design as needed.

Matthias Noback

Hi Ryan, ah, if only I had known :) Thanks anyway, and just like I said to Javier, you are doing something good with this. Symfony is great because of the fantastic amount of options you have to get things done. It is also a great playground for people like me who like to try new things.

I hope to see you in Madrid too, though I have to admit that I'll only be there if one of my talks gets selected ;)


I have no power in this, but I hope you do get accepted ;)

Matthias Noback

Thanks Ryan, that would be very nice indeed!