9 ms·

The consequences of living with a legacy PHP framework

72 points by tnorthcutt 13y ago

j_m_b 13y ago
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!
- jtreminio 13y ago
  Did you bother reading the extensive documentation? You can quickly figure out how to do this within 10 minutes for your first time.
- sheraz 13y ago
  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 13y ago
    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 13y ago
      Is Silex too heavy or too light for your usage?
      - jrgnsd 13y ago
        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 13y ago
        I wouldn't call Silex "lightweight". Slim, however, is very lightweight and a pleasure to use: http://slimframework.com/ http://slimframework.com/
      - porker 13y ago
        I think too light, but I don't think I've ever got the concept straight in my head. I thought it was a mapper from a URL parameter to a function - the first two code examples in http://web.archive.org/web/20130402141837/http://edorian.posterous.com/a-silex-love-story-embedded-php http://web.archive.org/web/20130402141837/http://edorian.pos... are what I understood it to be. TL;DR: I think Silex has changed a lot since I looked at it. I can't give you a good answer.
smacktoward 13y ago
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.
CognitiveLens 13y ago
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 13y ago
  I think it's probably generalizable to any codebase large enough to have a learning curve.
ohwp 13y ago
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 13y ago
  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 13y ago
    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.
- sybhn 13y ago
  I don't see that approach working in any competitive product marketplace. This is the kind of candy you don't want to throw to you competitor. Anecdotal, there's a company that built their core product on Symfony 0.9x, and never upgraded. That was started around 6 years ago. The company is now worth 1+ billion on nasdaq, and still relies on Symfony 0.9x for the core functionality. From a development point of view it sucks. Ask any developers. From the business point of view, staying away from the kind of 6 month no feature s-bugs-only period you're talking about, is probably the reason it could beat its main competitor, and succeed the way it did.
lnanek2 13y ago
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.
- myko 13y ago
  AFAIK there will be comparable tooling for Eclipse once the new build system is officially 'ready for production'.
- king_jester 13y ago
  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.
programminggeek 13y ago
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-architecture.html http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arch...
- mattgreenrocks 13y ago
  I hope this point gets more discussion. It's entirely possible to decouple yourself from a framework and move quickly. It's just that most devs are incredibly lazy, and most frameworks are specifically engineered to make this difficult.
  - gpvos 13y ago
    It's essentially true for any language (and its standard libraries).
    - mattgreenrocks 13y ago
      True, but languages/standard libraries don't break quite like frameworks do. This mostly due to the extreme coupling that a framework induces on client code. Frameworks mean you get to skip the design step, at the risk of having you by the balls later on.
      - fein 13y ago
kayoone 13y ago
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.
debacle 13y ago
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.
troels 13y ago
How big is this app? 6 months to port from one mvc framework to another seems quite excessive.
username42 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      > (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 13y ago
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/
contingencies 13y ago
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.
methodin 13y ago
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.
andybak 13y ago
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 13y ago
  It's good to point that out. I think he realizes that, but I'm not sure most of HN does.
astral303 13y ago
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).
jrochkind1 13y ago
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.
fesja 13y ago
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!
lurkinggrue 13y ago
Talk to any ColdFusion developers.

72 points by tnorthcutt 13y ago

j_m_b 13y ago

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!

jtreminio 13y ago
Did you bother reading the extensive documentation? You can quickly figure out how to do this within 10 minutes for your first time.
sheraz 13y ago
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 13y ago
  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 13y ago
    Is Silex too heavy or too light for your usage?
    - jrgnsd 13y ago
      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 13y ago
        I wouldn't call Silex "lightweight". Slim, however, is very lightweight and a pleasure to use: http://slimframework.com/ http://slimframework.com/
    - porker 13y ago
      I think too light, but I don't think I've ever got the concept straight in my head. I thought it was a mapper from a URL parameter to a function - the first two code examples in http://web.archive.org/web/20130402141837/http://edorian.posterous.com/a-silex-love-story-embedded-php http://web.archive.org/web/20130402141837/http://edorian.pos... are what I understood it to be. TL;DR: I think Silex has changed a lot since I looked at it. I can't give you a good answer.

smacktoward 13y ago

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.

CognitiveLens 13y ago

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 13y ago
I think it's probably generalizable to any codebase large enough to have a learning curve.

ohwp 13y ago

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 13y ago
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 13y ago
  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.
sybhn 13y ago
I don't see that approach working in any competitive product marketplace. This is the kind of candy you don't want to throw to you competitor. Anecdotal, there's a company that built their core product on Symfony 0.9x, and never upgraded. That was started around 6 years ago. The company is now worth 1+ billion on nasdaq, and still relies on Symfony 0.9x for the core functionality. From a development point of view it sucks. Ask any developers. From the business point of view, staying away from the kind of 6 month no feature s-bugs-only period you're talking about, is probably the reason it could beat its main competitor, and succeed the way it did.

lnanek2 13y ago

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.

myko 13y ago
AFAIK there will be comparable tooling for Eclipse once the new build system is officially 'ready for production'.
king_jester 13y ago
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.

programminggeek 13y ago

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-architecture.html http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arch...

mattgreenrocks 13y ago
I hope this point gets more discussion. It's entirely possible to decouple yourself from a framework and move quickly. It's just that most devs are incredibly lazy, and most frameworks are specifically engineered to make this difficult.
- gpvos 13y ago
  It's essentially true for any language (and its standard libraries).
  - mattgreenrocks 13y ago
    True, but languages/standard libraries don't break quite like frameworks do. This mostly due to the extreme coupling that a framework induces on client code. Frameworks mean you get to skip the design step, at the risk of having you by the balls later on.
    - fein 13y ago

kayoone 13y ago

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.

debacle 13y ago

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.

troels 13y ago

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

username42 13y ago

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 13y ago
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 13y ago
  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 13y ago
    > (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 13y ago

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/

contingencies 13y ago

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.

methodin 13y ago

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.

andybak 13y ago

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 13y ago
It's good to point that out. I think he realizes that, but I'm not sure most of HN does.

astral303 13y ago

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).

jrochkind1 13y ago

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.

fesja 13y ago

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!

lurkinggrue 13y ago

Talk to any ColdFusion developers.