
The consequences of living with a legacy PHP framework - tnorthcutt
http://blog.yannickmahe.com/symfony/2013/08/19/the-walking-dead.html
======
programminggeek
This is the consequence of writing code against ANY framework. I don't care if
it's Symfony, Zend, etc. in PHP, Rails in Ruby, or Spring, Struts, etc. in
Java. The more you lean on a framework, the more you are tied to it and the
harder it is to move.

Just look at all the pain Ruby devs have felt moving from various rails
versions. [https://railslts.com](https://railslts.com) shouldn't have to exist
if we were doing our job as software developers.

Using a framework is a HUGE tradeoff. You are trading ease of development for
a kind of vendor lock-in where the cost to move goes up with every line of
code you write.

Using an architecture that lets you write framework-independant code is a huge
win and would keep you out of this kind of trouble. I wrote Obvious
Architecture [http://obvious.retromocha.com](http://obvious.retromocha.com)
for this reason, but there are plenty of clean architecture examples here:
[http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-
arch...](http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-
architecture.html)

~~~
porker
Completely agree.

I wrote against Symfony 1.0 and the upgrade to 1.4 needed a partial rewrite
(look, new form library!).

I wrote against Symfony 1.4 and the upgrade to 2.X ..well hasn't happened, a
recession got in the way and clients want to spend money on something that'll
have results.

I don't mind legacy code - heck I make a good living from it. But I wish
framework developers (and everyone online) would agree that slower, more
evolutionary progress is OK.

\-- A cynical developer, who's seen fads come and go too many times

~~~
aryastark
frameworks and everything, say, post-2003 has been a tragic joke on our
profession. We deserve better, but everything JWZ says here is the norm:
[http://www.jwz.org/doc/cadt.html](http://www.jwz.org/doc/cadt.html). Even the
majors, like Google, are doing this today. Quality down, fads up.

------
smacktoward
These consequences are broadly generalizable to "pinning" yourself on any
particular version of a software package. The farther behind the current
version your pinned version gets, you'll be able to find less help on Google,
the ecosystem of compatible third-party packages will get smaller, the number
of flaky bugs you'll encounter when upgrading other parts of the stack will
get bigger, etc. A business who's still using (say) Windows 2000 on their
desktop machines will have all the same problems.

In other words, you don't want to live on the bleeding edge necessarily, but
it's a bad idea to let yourself get too far behind it too.

------
kayoone
As a longtime symfony user i think the biggest mistake here was to not upgrade
to 1.4..Even now the effort to upgrade to 1.4 should be worth it had a lot
longer lifecycle, more documentation and alot more people are still using it.
I also believe the effort should be fairly small compared to rewriting it
using Symfony 2.x. I am currently working on a huge Symfony2 project and we
update to the next version asap to avoid these kinds of problems. Its kind of
like merging a branch. If you merge master into your feature branch every day
and take the time to fix conflicts one by one it will be easy to merge back
into master. If you dont, and develop for weeks/months on your own it will be
alot of work to merge back.

------
andybak
Can I point out that nearly all of the issues he identified would have still
applied if he had used no framework or a home-grown one?

1\. Need to update to support newer PHP versions. Check.

2\. Lack of community support. Check.

3\. Can't draw on 3rd party plugins. Check.

etc.

Plus he would have had the burden of writing his own in the first place - or
the overhead of coding without a framework.

So - how does this lead to the conclusion that he would have been better off
not using Symfony?

The lesson I drew was "choose your framework wisely and don't accrue technical
debt".

~~~
frenchy
It's good to point that out. I think he realizes that, but I'm not sure most
of HN does.

------
debacle
It is relatively trivial to upgrade from 1.0 to 1.1 and 1.2 is as far as you
need to go to be able to use a more modern PHP. The biggest changes are how
the controller interacts with the model and views, which can be done with a
sed script in most instances.

Most plugins for 1.2 offer versions for both Prototype and jQuery.

In general, Symfony 1.* was easier to work with than 2.0. Symfony 2.0 feels
very much like a Java project in that they prefer mounds of configuration
files, reflection, annotations, etc, all to do something very simple - routing
and view management.

------
lnanek2
Same thing happening in Android development right now. You may have spent
years working with Eclipse and Ant and the ADT plugin for Eclipse to write
Android apps. Personally I have dozens of apps written using these. But now
everything new is happening on Android Studio and Gradle, the new IDE and
build system. If you want to use new features like binary Android library
packages, you have to switch to the new tooling.

~~~
king_jester
While its true the official build system is slowly lurching its way over to
gradle, this is nothing like what the author is experiencing with Symfony.
Android + ant is still fully functionally and has tons of documentation and
community info. Switching from ant builds to gradle is not difficult and
doesn't impact app development, Eclipse/Intellij/Android Studio all can build
and work with projects without gradle.

------
j_m_b
Symfony is somehow able to make PHP programming seem very elegant... I never
understood all the hate against PHP while tucked safely inside the framework.
The main drawback to Symfony is the endless amount of configuration that is
done through YAML files and pure PHP. The configuration files are spread
throughout the project dir and can be a bit confusing. To paraphrase a famous
quote: "I would rather have one configuration file that configures 100 things
than 10 configuration files that configure 10 things". After migrating to
Symfony 2.0, one day I wanted to make a simple column change in my database
and it took me TWO freakin' days to figure out how to properly configure the
ORM! I've since abandoned PHP/Symfony/Javascript for Clojure/Clojurescript and
I haven't looked back!

~~~
sheraz
I completely feel your pain with regard to Symfony. That, and the required
verbosity in coding left me feeling lost in a language I thought I knew.

Even after a couple projects I still didn't "get it." Most of my time was
spent in the docs and stack overflow trying to learn the "symfony way" of
doing things rather than just getting it done.

\- Too much nesting, both in file layout and yaml configurations \- Too many
different ways to do things (YAML, PHP, .ini, file annotations) \- Too verbose
when coding (namespaces, long class and method names) \- And don't get me
started with Twig

I took those hard knocks and tried to write my own mini-framework, which only
taught me why you don't write frameworks. It is really hard to do well.

Then I found laravel [1] and have been impressed. It is more opinionated than
Symfony and feels more cormfortable to develop on. Less configuration, less
verbosity. I combed through the docs and had a project up and running in two
days.

But here is the real nugget, kids. Using a framework on a long-term project is
like marriage. It takes commitment. You will be in it for a while, so you had
better make sure you can live with it. You have to invest your time and effort
into it to understand it as much as possible -- warts and all.

~~~
porker
What kind of apps or websites were you developing sheraz? I'd like something
less complex than Symfony, but Laravel doesn't seem as feature-complete for
complex applications. Form definitions seem much more lightweight (I build 9+
page loan application forms, multi-page legal forms with repeating regions,
add-remove rows etc), APIs and REST interfaces - the works. I want to change
framework, but I get the impression most of the others have a smaller-project
sweet spot.

[And yes, I know large stuff can be built with the others, like it can with
Drupal. But does the framework make it as/more easy than Symfony, that's the
question?]

A free rant :): I hate the Doctrine ORM for it's hideously bad documentation
(either missing information or written by core devs for core devs -- I can't
contribute to improving it as I don't understand it well enough!) yet I
appreciate a 'real' ORM vs an ActiveRecord+QueryBuilder system. Gah.

~~~
MAGZine
Is Silex too heavy or too light for your usage?

~~~
jrgnsd
Silex is definitely a good lightweight alternative. For enterprise work
Symfony 2 is a better choice, but if you need to throw things together (but
need to keep the option of adding more features without writing them yourself)
you can easily integrate a bunch of the Symfony 2 components into Silex.

~~~
wldlyinaccurate
I wouldn't call Silex "lightweight". Slim, however, is very lightweight and a
pleasure to use: [http://slimframework.com/](http://slimframework.com/)

------
CognitiveLens
I'll be interested to follow the comments about this problem, because it seems
to me that it can be generalized to working with any legacy backend system. In
my first job it was an 8 year old custom CMS built in ASP classic, then it was
a home-grown PHP CMS, then a very large Java BE codebase - in each case I felt
that the existing system made very aspect of development more difficult than
it "could be" with a more current framework (1/3rd productivity loss was a
major underestimate in some cases).

I am interested in people's experiences with using a third-party system and
trying to keep it updated versus using an in-house system that gradually
becomes more difficult to update/maintain.

Sometimes a state of permanent updates can be just as limiting.

~~~
rhizome
I think it's probably generalizable to any codebase large enough to have a
learning curve.

------
username42
I am not expert, but I have listened to a course where the teacher said that
we should use many frameworks. When you develop a project for a client, you
select the current best framework and you do not change until you really need
to change. Then when you have a new project for a new client, you use the new
best framework.

I do not know if it is feasible in all cases. Having many frameworks allows to
anticipate the problems, cost and benefits of a migration. I think it is
interesting for developers who will have more interesting work. The cost of
many framework may be compensate by the fact that it is easier to associate a
migration cost to a client.

~~~
rypskar
As I see it if you are developing something small for a client, you want to
get something created ASAP get it out and forget about it. So yes, then it
makes sense to use the current best framework and write code that is tightly
coupled with it.

But when you start to create larger systems, you will have to think about
maintaining the code, adding new features and fixing bugs. Then it is not so
fun if your code depends too much on a framework and you don’t update it when
new versions are released. It is not fun googling for something and in the one
result you get someone is pointing out that you are using an obsolete
framework, and noticing that the post is 10 years old. (Did happen with some
software I used to be developer on)

~~~
webreac
There is also an answer for that: do not build large system. Split them into
largely independant parts (I think this is called silo architecture). When one
of your silos get outdated, you replace it.

~~~
csixty4
> (I think this is called silo architecture)

Might be called that now. When I was working on big systems it was called
Service Oriented Architecture.

------
wldlyinaccurate
This is why I strongly believe in writing framework-agnostic code. The extra
effort of splitting even small bits functionality into decoupled components
can save _so_ many headaches in the future.

When I'm writing a new feature, I always try and code it as if I'm going to
release it as a standalone library that could easily work for other people
regardless of what framework they're using.

Stuart Herbert wrote a lot about this: [http://blog.stuartherbert.com/php/php-
components/](http://blog.stuartherbert.com/php/php-components/)

------
ohwp
The company I work for also had this problem.

The solutions was in fact simple: we told our customers we wouldn't add any
features or changes other than bugfixes. When you are telling the software is
outdated and the support is gone they all understand it's time to move on [1].

Most of the time the customer also wants to get rid of the outdated
website/webapp. So it's also a good reason to start something new.

[1] Ofcourse this doesn't work for all customers.

~~~
gpvos
The way you describe it, I understand the customers moved to a competitor and
the company went out of business.

Or did you have a new version ready and at (near) feature parity with the old
version? As the article describes, that investment can become very large when
you put it off for too long. And the reasons they had to put it off were, at
least initially, quite valid.

~~~
ohwp
Ofcourse there should be a better alternative at the time you tell your
customers to move on. But no, they didn't run to competitors. I don't want to
sound very arrogant, but when your work is good, customers will stay because
they trust you.

------
astral303
How much functional/end-user automated testing do you have? That's probably
the biggest roadblock to roll with things like 1.0 to 1.x upgrades. Why are
migrations considered risky? Is it risky because the functionality will break?
Or is it risky because the next point release (say 1.2) is considered
unstable?

Because the latter fixes itself with time as the community tests version 1.2
and patches come out, but not having tests for your own code that don't rely
on the framework prevents you from being able to move fast on anything but the
smallest of refactorings.

I think that's how you can get yourself out. Ruthlessly write end-user
acceptance tests (something that drives a browser, headless or not, Selenium,
PhantomJS/CasperJs, etc etc) that verify all your functionality. Only once you
can quickly and automatically verify correct operation can you then do
something like a framework migration (even if to latest Symfony 1.x).

------
fesja
I started TouristEye.com 4 years ago with Symfony 1.1. We kept pace with the
new releases (updating when 1.2.2, 1.3.2, 1.4.2 was out). Last November we
decided to simplify our website and completely change our website, so we felt
it was the right time to do the migration. It took 5 months (myself as the
backend of the website & api, and another developer as the frontend). It was a
big rewrite, but the code now is so much better to maintain and learn. We are
right now using 2.3, and I'm way happy coding :)

About your case, I agree with you that the best way for you is to add
component by component, extracting and encapsulating functionality so you can
use Symfony2, Zend or whatever framework you want in the future. Go for a
service oriented architecture. And let's hope you have everything tested!

------
methodin
This is a problem with software in general. Lazy developers or ignorant bosses
stagnate the code to the point where it requires a massive rewrite to bring it
up to speed.

Right now I maintain about 70/30 old code to new code. Most of the old code is
because previous developers didn't care at all and were more interested in job
stability than code stability. You make a conscious effort to not follow the
trends with the framework and thus can only blame yourself for the outcome.

------
contingencies
_I think the lack of reusability comes in object-oriented languages, not in
functional languages. Because the problem with object-oriented languages is
they 've got all this implicit environment that they carry around with them.
You wanted a banana but what you got was a gorilla holding the banana and the
entire jungle._ \- Joe Armstrong, creator of Erlang. As quoted in _Coders at
Work: Reflections on the Craft of Programming_ by Peter Seibel.

------
jrochkind1
It's not just PHP, if you're stuck in Rails 2 (let alone somehow Rails1?! )
you're going to have similar problems.

It is a problem -- I have apps that i only barely got upgraded from rails 2 to
3 before 4 came out. Hopefully upgrading to 4 won't be as much of a
nightmare... but I'm still procrastinating it, even though I know if I wait
too long to do it it will just get worse.

------
troels
How big is this app? 6 months to port from one mvc framework to another seems
quite excessive.

------
lurkinggrue
Talk to any ColdFusion developers.

